Mar
24

IPv6 multicast routing is a fun topic, and is often either loved or avoided :). Here is a jump-start for all my CCIE candidate friends.

Readers digest version: “Auto-RP is out, Dense-mode is out, IGMP is replaced with Multicast Listener Discovery (MLD). MLDv2 supports SSM. RPs, Bi-directional PIM, SSM, ASM and BSRs are still alive and well, and we can now avoid static RPs and BSR if we choose to use embedded RP within the multicast packets themselves. (Crazy and amazing stuff).

Want a little more? Then read on. In this multi-part blog, we will discuss static RP, BSR, and Embedded RP. This first blog will discuss static RP, with some examples that will assist you in getting started.  For those of you who subscribe the open lecture series, I will be including all three RP options in a discussion there as well.

Here is the topology we will use:

IPV6 Multicasting

Here is some additional info on the topology. There is a loopback 0 interface on each router using 2002:yyyy::y/64, where y = the router number. We also hard coded the MAC addresses to 00yy.yyyy.yyyy so that they would be easy to spot. OSPFv3 is running on each interface shown in the diagram including the loopbacks. Let’s verify some basic addressing and connectivity before we add IPv6 multicast routing to the mix.

R3#show ipv6 int brief
FastEthernet0/0 [up/up]
FE80::233:33FF:FE33:3333
2002:34::3
Serial0/1 [up/up]
Serial0/1.23 [up/up]
FE80::C003:8FF:FECC:0
2002:23::3
Loopback0 [up/up]
FE80::C003:8FF:FECC:0
2002:3333::3

R3#show ipv6 route ospf
IPv6 Routing Table - 17 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
O 2002:12::/64 [110/5]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:14::/64 [110/65]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:16::/64 [110/4]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:45::/64 [110/2]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:56::/64 [110/3]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:1111::1/128 [110/4]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:2222::2/128 [110/5]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:4444::4/128 [110/1]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:5555::5/128 [110/2]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
O 2002:6666::6/128 [110/3]
via FE80::244:44FF:FE44:4444, FastEthernet0/0
R3#

Looks like everything is there. Lets do an IPv6 traceroute to verify. Note the path that begins from R3, then through R4 -> R5 -> R6 -> R1 -> R2. That is the path the OSPFv3 control plane sorted out. It will be important later, when we see what the RPF path is from R3 to R2.

R3#traceroute ipv6 2002:2222::2

Type escape sequence to abort.
Tracing the route to 2002:2222::2

1 2002:34::4 80 msec 28 msec 4 msec
2 2002:45::5 44 msec 40 msec 24 msec
3 2002:56::6 4 msec 32 msec 32 msec
4 2002:16::1 40 msec 28 msec 24 msec
5 2002:2222::2 84 msec 8 msec 20 msec
R3#

OK, I am sold that we have connectivity. Lets verify that PIM, MLD and Multicast-Routing is not currently enabled yet.

R3#show ipv6 pim interface
No interfaces found.

R3#show ipv6 mld interface

FastEthernet0/0 is up, line protocol is up
Internet address is FE80::233:33FF:FE33:3333/10
MLD is disabled on interface

Loopback0 is up, line protocol is up
Internet address is FE80::C003:8FF:FECC:0/10
MLD is disabled on interface
Serial0/1.23 is up, line protocol is up
Internet address is FE80::C003:8FF:FECC:0/10
MLD is disabled on interface
R3#

Lets enable ipv6 multicast routing, and see the difference on R3.

R3(config)#ipv6 multicast-routing

R3#show ipv6 pim interface
Interface PIM Nbr Hello DR
Count Intvl Prior

Tunnel0 off 0 30 1
Address: FE80::C003:8FF:FECC:0
DR : not elected

FastEthernet0/0 on 0 30 1
Address: FE80::233:33FF:FE33:3333
DR : this system

Loopback0 on 0 30 1
Address: FE80::C003:8FF:FECC:0
DR : this system
Serial0/1.23 on 0 30 1
Address: FE80::C003:8FF:FECC:0
DR : this system

R3#show ipv6 mld interface
Tunnel0 is up, line protocol is up
Internet address is FE80::C003:8FF:FECC:0/10
MLD is disabled on interface

FastEthernet0/0 is up, line protocol is up
Internet address is FE80::233:33FF:FE33:3333/10
MLD is enabled on interface
Current MLD version is 2
MLD query interval is 125 seconds
MLD querier timeout is 255 seconds
MLD max query response time is 10 seconds
Last member query response interval is 1 seconds
MLD activity: 9 joins, 0 leaves
MLD querying router is FE80::233:33FF:FE33:3333 (this system)

Loopback0 is up, line protocol is up
Internet address is FE80::C003:8FF:FECC:0/10
MLD is enabled on interface
Current MLD version is 2
MLD query interval is 125 seconds
MLD querier timeout is 255 seconds
MLD max query response time is 10 seconds
Last member query response interval is 1 seconds
MLD activity: 6 joins, 0 leaves
MLD querying router is FE80::C003:8FF:FECC:0 (this system)
Serial0/1.23 is up, line protocol is up
Internet address is FE80::C003:8FF:FECC:0/10
MLD is enabled on interface
Current MLD version is 2
MLD query interval is 125 seconds
MLD querier timeout is 255 seconds
MLD max query response time is 10 seconds
Last member query response interval is 1 seconds
MLD activity: 7 joins, 0 leaves
MLD querying router is FE80::C003:8FF:FECC:0 (this system)

R3#

Just adding the global command of “ipv6 multicast-routing” enabled MLD on the interfaces, and enabled PIM as well. The tunnel created is used to send register messages to RPs when multicast content is seen. The command was so easy, I added the command to the other 5 routers as well. (Not shown here, but if you want to see it, just revisit the previous command in the previous example 5 more times.  :)

Now we can take a look at some additional information such as the tunnel interface that was created and neighborships from a PIM perspective.

R3#show ipv6 int brief
FastEthernet0/0 [up/up]
FE80::233:33FF:FE33:3333
2002:34::3
Serial0/1 [up/up]
Serial0/1.23 [up/up]
FE80::C003:8FF:FECC:0
2002:23::3
Loopback0 [up/up]
FE80::C003:8FF:FECC:0
2002:3333::3
Tunnel0 [up/up] FE80::C003:8FF:FECC:0 unnumbered (FastEthernet0/0)

R3#show ipv6 pim neighbor
Neighbor Address Interface Uptime Expires DR pri Bidir

FE80::244:44FF:FE44:4444 FastEthernet0/0 00:00:55 00:01:21 1 (DR) B
FE80::C002:8FF:FECC:0 Serial0/1.23 00:00:57 00:01:18 1 B

R3#

Looks like R4 won the DR election on the FA0/0 segment. All is fair in love and multicast.   (Earlier, before R4 was enabled for multicast routing, R3 was the DR, and R4 is now the DR for the segment due to a higher IP address on R4).
Next we will set up hard code an RP for the entire domain to use. R2’s loopback0 will do fine. We will use the following command on R2, as well as all the other 5 routers.

R2(config)#ipv6 pim rp-address 2002:2222::2
%SYS-5-CONFIG_I: Configured from console by console
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
R2#

On R2, PIM tunnels are automagically created. These are used for initial register messages. In sparse mode, the RP will build a shortest path tree (by default), in the direction of the multicast source.

R2#show ipv6 pim tunnel
Tunnel0*
Type : PIM Encap
RP : Embedded RP Tunnel
Source: 2002:12::2
Tunnel1*
Type : PIM Encap
RP : 2002:2222::2*
Source: 2002:12::2
Tunnel2*
Type : PIM Decap
RP : 2002:2222::2*
Source: -

R2#

Lets see if everyone agrees that R2 should be the RP. They should, since we hard coded it on all 6 routers. We will do a quick check on R3. All the others should be similar.

R3#show ipv6 pim group-map ff00::/8
IP PIM Group Mapping Table
(* indicates group mappings being used)

FF00::/8*
SM, RP: 2002:2222::2
RPF: Fa0/0,FE80::244:44FF:FE44:4444
Info source: Static
Uptime: 00:04:44, Groups: 0
FF00::/8
SM
Info source: Default
Uptime: 00:17:22, Groups: 0

R3#

Sweet! Since we are on R3, let’s have R3’s loopback 0 interface join a multicast group. IGMP has been replaced in IPv6 multicast with Multicast Listener Discovery (MLD), which uses IPv6 ICMP for communications. Lets use the group of FF08:AAAA::1.

R3(config)#int lo 0
R3(config-if)#ipv6 mld join-group FF08:AAAA::1

Lets look at the mroute table. It appears that R3 is ready willing and able to get that stream of traffic. We should follow the path upstream, and see if the join went all the way to R2, (the RP).

R3#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:00:32/never, RP 2002:2222::2, flags: SCLJ Incoming interface: FastEthernet0/0 RPF nbr: FE80::244:44FF:FE44:4444 Immediate Outgoing interface list: Loopback0, Forward, 00:00:32/never
R3#

R4#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:02:40/00:02:47, RP 2002:2222::2, flags: S Incoming interface: FastEthernet0/1 RPF nbr: FE80::255:55FF:FE55:5555 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:02:40/00:02:47 R4#

R5#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:02:57/00:03:27, RP 2002:2222::2, flags: S Incoming interface: FastEthernet0/0 RPF nbr: FE80::266:66FF:FE66:6666 Immediate Outgoing interface list: FastEthernet0/1, Forward, 00:02:57/00:03:27
R5#

R6#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:03:17/00:03:08, RP 2002:2222::2, flags: S Incoming interface: FastEthernet0/1 RPF nbr: FE80::211:11FF:FE11:1111 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:03:17/00:03:08
R6#

R1#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:03:39/00:02:47, RP 2002:2222::2, flags: S Incoming interface: FastEthernet0/0 RPF nbr: FE80::222:22FF:FE22:2222 Immediate Outgoing interface list: FastEthernet0/1, Forward, 00:03:39/00:02:47
R1#

R2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:04:05/00:03:25, RP 2002:2222::2, flags: S Incoming interface: Tunnel2 RPF nbr: 2002:2222::2 Immediate Outgoing interface list: FastEthernet0/0, Forward, 00:04:05/00:03:25 R2#

Looks like the join for that group went all the way back to the RP. (One of the reasons I did the traceroute earlier, was to show the unicast routing path for IPv6). Notice that the RPF path back to the RP of 2002:2222::2, follows the same path the traceroute did. Convenient, isn’t it.

Ok, so now we just need some content. We can use R6 to emulate a mcast server for that group, by doing a ping. First lets do a debug of ipv6 pim on the RP, R2.

R2#debug ipv6 pim
IPv6 PIM debugging is on

Now a ping from R6.

R6#ping ff08:aaaa::1
Output Interface: Fastethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF08:AAAA::1, timeout is 2 seconds:
Packet sent with a source address of 2002:56::6

Reply to request 0 received from 2002:3333::3, 248 ms
Reply to request 1 received from 2002:3333::3, 64 ms
Reply to request 2 received from 2002:3333::3, 80 ms
Reply to request 3 received from 2002:3333::3, 72 ms
Reply to request 4 received from 2002:3333::3, 84 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/109/248 ms
5 multicast replies and 0 errors.

Cool. Lets look at the debug output on the RP.

IPv6 PIM: Received J/P on FastEthernet0/0 from FE80::211:11FF:FE11:1111 target: FE80::222:22FF:FE22:2222 (to us)
IPv6 PIM: J/P entry: Join root: 2002:2222::2 group: FF08:AAAA::1 flags: RPT WC S
IPv6 PIM: (*,FF08:AAAA::1) FastEthernet0/0 Raise J/P expiration timer to 210 seconds

Lets also investigate R5, in the path between R6 (the mcast server) and the R3 (who joined the group)

R5#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:11:18/00:03:06, RP 2002:2222::2, flags: S
Incoming interface: FastEthernet0/0
RPF nbr: FE80::266:66FF:FE66:6666
Immediate Outgoing interface list:
FastEthernet0/1, Forward, 00:11:18/00:03:06

(2002:56::6, FF08:AAAA::1), 00:03:09/00:00:20, flags: ST Incoming interface: FastEthernet0/0 RPF nbr: FE80::266:66FF:FE66:6666 Immediate Outgoing interface list: FastEthernet0/1, Forward, 00:03:08/00:03:16
R5#

Another command that provides additional information is the show ipv6 pim topology command.

R5#show ipv6 pim topology
IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,
RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,
RR - Register Received, SR - Sending Registers, E - MSDP External,
DCC - Don't Check Connected
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Disinterest,
II - Internal Interest, ID - Internal Disinterest,
LH - Last Hop, AS - Assert, AB - Admin Boundary

(*,FF08:AAAA::1)
SM UP: 00:11:53 JP: Join(now) Flags:
RP: 2002:2222::2
RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666
FastEthernet0/1 00:11:53 fwd Join(00:02:31)

(2002:56::6,FF08:AAAA::1) SM SPT UP: 00:03:44 JP: Join(never) Flags: KAT(00:00:50) AA PA RA RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666* FastEthernet0/1 00:03:44 fwd Join(00:02:41)
R5#

That’s a great little jumpstart into IPv6 multicast.

One item of note, is that hard coding the RP is not very scalable. The other options include BSR and Embedded RP (where the actual multicast traffic has the RP embedded within the packet itself). I will include those examples in another blog post. Or if you can’t wait, jump right into our RS workbooks for a wealth of information, insight and practice labs to improve your Tier1, Tier2 and Tier3 skills.

Any skills you develop in IPv4 multicasting will greatly assist you with the IPv6 multicasting, and they are both on the blueprint.

Best wishes.

Jan
14

IOS IPS is fair game for the CCIE Security and CCIE R/S labs. With IOS IPS now using v5 signatures, (just like the sensor appliance), the ability to setup up IOS is not as simple, but very important. The intention of this post is to provide a streamlined process to use as a jumpstart into IOS IPS. For full details, examples and explanations, please refer to our lab workbooks. Both RS and Security cover the topic.   Lets get started!

First, we need a place for IPS configuration files to call home. IPS wants a folder. Lets make a directory on the router flash. Optionally if there were other IOS file systems present, we could use those writable file systems as well.

R6#mkdir ips
Create directory filename [ips]?
Created dir flash:/ips
R6#

IOS IPS uses a crypto key to verify the digital signature for the master signature file, which is signed using a private key. To verify the signature, we need a corresponding public key. This key is available as a text file on Cisco’s site. The file is called realm-cisco.pub.key.txt. To inject the public key into the router config, we would do the following:

R6(config)#crypto key pubkey-chain rsa
R6(config-pubkey-chain)#named-key realm-cisco.pub signature
Translating "realm-cisco.pub"
R6(config-pubkey-key)#key-string
Enter a public key as a hexidecimal number ....
! Note: The $ to the left of the hex characters represent there are more numbers present than would fit on one line.
R6(config-pubkey)#$2A864886 F70D0101 01050003 82010F00 3082010A 02820101
R6(config-pubkey)#$D6CC7A24 5097A975 206BE3A2 06FBA13F 6F12CB5B 4E441F16
R6(config-pubkey)#$912BE27F 37FDD9C8 11FC7AF7 DCDD81D9 43CDABC3 6007D128
R6(config-pubkey)#$085FADC1 359C189E F30AF10A C0EFB624 7E0764BF 3E53053E
R6(config-pubkey)#$0298AF03 DED7A5B8 9479039D 20F30663 9AC64B93 C0112A35
R6(config-pubkey)#$994AE74C FA9E481D F65875D6 85EAF974 6D9CC8E3 F0B08B85
R6(config-pubkey)#$5E4189FF CC189CB9 69C46F9C A84DFBA5 7A0AF99E AD768C36
R6(config-pubkey)#$A3B3FB1F 9FB7B3CB 5539E1D1 9693CCBB 551F78D2 892356AE
R6(config-pubkey)#$80CA4F4D 87BFCA3B BFF668E9 689782A5 CF31CB6E B4B094D3
R6(config-pubkey)# F3020301 0001
R6(config-pubkey)# quit
R6(config-pubkey-key)#end

We’ll save the configuration, just to be safe.

R6#wr
Building configuration...

Let’s check the ips folder we created on flash. It should still be empty.

R6#cd ips
R6#dir
Directory of flash:/ips/

No files in directory

255967232 bytes total (187428864 bytes free)
R6#cd ..

Once we complete the IPS configuration, the router can monitor all traffic on the interface and direction we specify. If we want to limit the traffic that goes through the IPS processing, we can use an access-list to filter. Only traffic permitted in the ACL will be subjected to IPS analysis. Let’s create an ACL that matches only on traffic destined to 6.6.6.6, which is the loopback of R6.

R6(config)#<strong>access-list 123 permit ip any host 6.6.6.6</strong>

Next we will create an IPS rule named “IOS-IPS”, and associate the ACL we just created. In a later step, we will apply IPS rule to an interface.

R6(config)#<strong>ip ips name IOS-IPS list 123</strong>

IPS needs to know where to keep it’s signature definitions and configurations. It just so happens that we have a folder on flash we created earlier named “ips”. We will use that directory.

R6(config)#<strong>ip ips config location flash:/ips</strong>

The router can send alerts using Security Device Event Exchange (SDEE) and/or Syslog. We will configure both, and allow up to 2 simultaneous SDEE managers to setup up requests for alerts called subscriptions. To use SDEE, http server must be enabled on the router. Lets take care of these items next.

R6(config)#ip ips notify sdee
R6(config)#ip sdee subscriptions 2
R6(config)#ip ips notify log
R6(config)#ip http server

Before we apply the IPS rule to an interface, we are going to set up some safety. We will retire all the signatures, and then enable just the signatures in the “advanced” default set. If we un-retired the “all” category, it is possible that the router could run out of memory. (Your mileage may vary☺) As we exit out of the configuration, we are prompted to accept the changes.

R6(config)#ip ips signature-category
R6(config-ips-category)#category all
R6(config-ips-category-action)#retired true
R6(config-ips-category-action)#exit
R6(config-ips-category)#
R6(config-ips-category)#category ios_ips advanced
R6(config-ips-category-action)#retired false
R6(config-ips-category-action)#end
Do you want to accept these changes? [confirm]
R6#
Applying Category configuration to signatures ...
R6#

Next we will apply the ips rule we created to an interface. We also enable virtual-reassembly so that IPS can better analyze sessions and attacks that comprise multiple packets.

R6(config)#interface FastEthernet0/0
R6(config-if)#ip ips IOS-IPS in
R6(config-if)#ip virtual-reassembly

Notice that after we apply the IPS rule to an interface, the router begins to compile signatures. This won’t take long at this point, due to the fact that we haven’t given the router a signature package (yet).

R6#
%IPS-6-ENGINE_BUILDS_STARTED: Jan 14 2010
%IPS-6-ENGINE_BUILDING: atomic-ip - 3 signatures - 1 of 13 engines
%IPS-6-ENGINE_READY: atomic-ip - build time 8 ms - packets for this engine will be scanned
%IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 12 ms

Lets take a peek at the ips directory that was empty just few minutes ago.

R6#cd ips
R6#dir
Directory of flash:/ips/

52 -rw- 719 Jan 14 2010 20:00:26 +00:00 R6-sigdef-default.xml
9 -rw- 271 Jan 14 2010 20:00:26 +00:00 R6-sigdef-delta.xml
59 -rw- 4365 Jan 14 2010 20:00:28 +00:00 R6-sigdef-typedef.xml
4 -rw- 1469 Jan 14 2010 20:00:28 +00:00 R6-sigdef-category.xml
7 -rw- 257 Jan 14 2010 20:00:28 +00:00 R6-seap-delta.xml
16 -rw- 491 Jan 14 2010 20:00:28 +00:00 R6-seap-typedef.xml

255967232 bytes total (187400192 bytes free)
R6#cd ..

Cool beans! Here is what those files contain:
R6-sigdef-default.xml: factory default signature definitions
R6-sigdef-delta.xml: signature definitions which were changed from the default
R6-sigdef-typedef.xml: signature parameter definitions
R6-sigdef-category.xml: signature category information, such as category ios_ips basic and advanced
R6-seap-delta.xml: has changes made to the default SEAP parameters
R6-seap-typedef.xml: has the default SEAP parameter definitions
SEAP = Signature Event Action Processor. Event Overrides/Filters, etc

Now lets give the router some signature information to crunch. We can download the latest signature packages from cisco.com, and put them on a local server. Here, R6 is copying the .pkg file from a local tftp server.

R6#copy tftp://40.0.0.101/IOS-S456-CLI.pkg idconf
Loading IOS-S456-CLI.pkg from 40.0.0.101 (via FastEthernet0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 11085111 bytes]

Now check out the console, while the router digests the file, and compiles all the signatures from the “advanced” set. This will take a while, and if on a production router, could case a DoS. CPU skyrockets, and it takes about 1 – 5 minutes to complete.

R6#
%IPS-6-ENGINE_BUILDS_STARTED: 20:03:39 UTC Jan 14 2010
%IPS-6-ENGINE_BUILDING: multi-string - 40 signatures - 1 of 13 engines
%IPS-6-ENGINE_READY: multi-string - build time 164 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: service-http - 801 signatures - 2 of 13 engines
%IPS-6-ENGINE_READY: service-http - build time 17456 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: string-tcp - 2058 signatures - 3 of 13 engines
%IPS-6-ENGINE_READY: string-tcp - build time 59236 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: string-udp - 79 signatures - 4 of 13 engines
%IPS-6-ENGINE_READY: string-udp - build time 52 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: state - 37 signatures - 5 of 13 engines
%IPS-6-ENGINE_READY: state - build time 648 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: atomic-ip - 373 signatures - 6 of 13 engines
%IPS-6-ENGINE_READY: atomic-ip - build time 5548 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: string-icmp - 3 signatures - 7 of 13 engines
%IPS-6-ENGINE_READY: string-icmp - build time 0 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: service-ftp - 3 signatures - 8 of 13 engines
%IPS-6-ENGINE_READY: service-ftp - build time 20 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: service-rpc - 76 signatures - 9 of 13 engines
%IPS-6-ENGINE_READY: service-rpc - build time 204 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: service-dns - 39 signatures - 10 of 13 engines
%IPS-6-ENGINE_READY: service-dns - build time 60 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: normalizer - 9 signatures - 11 of 13 engines
%IPS-6-ENGINE_READY: normalizer - build time 4 ms - packets for this engine will be scanned
%IPS-6-ENGINE_READY: service-smb-advanced - build time 3024 ms - packets for this engine will be scanned
%IPS-6-ENGINE_BUILDING: service-msrpc - 35 signatures - 13 of 13 engines
%IPS-6-ENGINE_READY: service-msrpc - build time 2208 ms - packets for this engine will be scanned
%IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 88876 ms
R6#

Wow, only 88,876 ms to complete. About 1.5 minutes. Lets do some show commands to verify our install.

R6#show ip ips signature count 

Cisco SDF release version S456.0
Trend SDF release version V0.0

Signature Micro-Engine: multi-string: Total Signatures 40
multi-string enabled signatures: 34
multi-string retired signatures: 34
multi-string compiled signatures: 6

Signature Micro-Engine: service-http: Total Signatures 801
service-http enabled signatures: 133
service-http retired signatures: 667
service-http compiled signatures: 134
service-http obsoleted signatures: 3

Signature Micro-Engine: string-tcp: Total Signatures 2058
string-tcp enabled signatures: 675
string-tcp retired signatures: 1810
string-tcp compiled signatures: 248
string-tcp obsoleted signatures: 22

Signature Micro-Engine: string-udp: Total Signatures 79
string-udp enabled signatures: 0
string-udp retired signatures: 78
string-udp compiled signatures: 1
string-udp obsoleted signatures: 2

Signature Micro-Engine: state: Total Signatures 37
state enabled signatures: 16
state retired signatures: 24
state compiled signatures: 13

Signature Micro-Engine: atomic-ip: Total Signatures 373
atomic-ip enabled signatures: 90
atomic-ip retired signatures: 307
atomic-ip compiled signatures: 66

Signature Micro-Engine: string-icmp: Total Signatures 3
string-icmp enabled signatures: 0
string-icmp retired signatures: 3

Signature Micro-Engine: service-ftp: Total Signatures 3
service-ftp enabled signatures: 1
service-ftp retired signatures: 2
service-ftp compiled signatures: 1

Signature Micro-Engine: service-rpc: Total Signatures 76
service-rpc enabled signatures: 44
service-rpc retired signatures: 50
service-rpc compiled signatures: 26

Signature Micro-Engine: service-dns: Total Signatures 39
service-dns enabled signatures: 27
service-dns retired signatures: 10
service-dns compiled signatures: 29
service-dns obsoleted signatures: 1

Signature Micro-Engine: normalizer: Total Signatures 9
normalizer enabled signatures: 8
normalizer retired signatures: 1
normalizer compiled signatures: 8

Signature Micro-Engine: service-smb-advanced: Total Signatures 49
service-smb-advanced enabled signatures: 40
service-smb-advanced retired signatures: 30
service-smb-advanced compiled signatures: 19

Signature Micro-Engine: service-msrpc: Total Signatures 35
service-msrpc enabled signatures: 17
service-msrpc retired signatures: 28
service-msrpc compiled signatures: 7
service-msrpc obsoleted signatures: 1

Total Signatures: 3602
Total Enabled Signatures: 1085
Total Retired Signatures: 3044
Total Compiled Signatures: 558
Total Obsoleted Signatures: 29

R6#show ip ips configuration

IPS Signature File Configuration Status
Configured Config Locations: flash:/ips/
Last signature default load time: Jan 14 2010
Last signature delta load time: Jan 14 2010
Last event action (SEAP) load time: -none-

General SEAP Config:
Global Deny Timeout: 3600 seconds
Global Overrides Status: Enabled
Global Filters Status: Enabled

IPS Auto Update is not currently configured

IPS Syslog and SDEE Notification Status
Event notification through syslog is enabled Event notification through SDEE is enabled

IPS Signature Status
Total Active Signatures: 558
Total Inactive Signatures: 3044

IPS Packet Scanning and Interface Status
IPS Rule Configuration IPS name IOS-IPS acl list 123
IPS fail closed is disabled
IPS deny-action ips-interface is false
Interface Configuration
Interface FastEthernet0/0
Inbound IPS rule is IOS-IPS acl list 123
Outgoing IPS rule is not set

IPS Category CLI Configuration:
Category all:
Retire: True
Category ios_ips advanced: Retire: False

R6#

Ok, how do we modify signatures? Simple, use Security Device Manager, the GUI. Unfortunately in the lab, that option is not available, so lets take a look at how to do it from CLI. We’ll modify the signature for ICMP echo request. If you are in a security lab, the IPS Sensor GUI (IDM) could be used on an appliance to discover which signature number is ICMP echo. In the R/S lab, online doc or the signature number in a task would be helpful. Signature 2004, sub-signature 0 is the signature for ICMP echo.

Lets look at the default for this signature first:

R6#show ip ips signature sigid 2004 subid 0

En - possible values are Y, Y*, N, or N*
Y: signature is enabled
N: enabled=false in the signature definition file
*: retired=true in the signature definition file
Cmp - possible values are Y, Ni, Nr, Nf, or No
Y: signature is compiled
Ni: signature not compiled due to invalid or missing parameters
Nr: signature not compiled because it is retired
Nf: signature compile failed
No: signature is obsoleted
Action=(A)lert, (D)eny, (R)eset, Deny-(H)ost, Deny-(F)low
Trait=alert-traits EC=event-count AI=alert-interval
GST=global-summary-threshold SI=summary-interval SM=summary-mode
SW=swap-attacker-victim SFR=sig-fidelity-rating Rel=release

SigID:SubID En Cmp Action Sev Trait EC AI GST SI SM SW SFR Rel
----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---
2004:0 N* Nr A INFO 0 1 0 200 30 FA N 100 S1
sig-name: ICMP Echo Request
sig-string-info: My Sig Info
sig-comment: Sig Comment
Engine atomic-ip params:
fragment-status :
icmp-type : 8
l4-protocol : icmp
R6#

Now we will tweak this signature. Take a look at the config, and it is apparent what we are configuring: true. (you may get the joke, after looking at the config: true, or not:  false :)

R6(config)#ip ips signature-definition
R6(config-sigdef)#signature 2004 0
R6(config-sigdef-sig)#engine
R6(config-sigdef-sig-engine)#event-action produce-alert
R6(config-sigdef-sig-engine)#exit
R6(config-sigdef-sig)#alert-severity high
R6(config-sigdef-sig)#status
R6(config-sigdef-sig-status)#enabled true
R6(config-sigdef-sig-status)#retired false
R6(config-sigdef-sig-status)#exit
R6(config-sigdef-sig)#exit
R6(config-sigdef)#exit
Do you want to accept these changes? [confirm]
R6(config)#
%IPS-6-ENGINE_BUILDS_STARTED: Jan 14 2010
%IPS-6-ENGINE_BUILDING: atomic-ip - 373 signatures - 1 of 13 engines
%IPS-6-ENGINE_READY: atomic-ip - build time 4764 ms - packets for this engine will be scanned
%IPS-6-ALL_ENGINE_BUILDS_COMPLETE: elapsed time 5596 ms
R6(config)#exit

Now lets look at the results of the changes.

R6#show ip ips signature sigid 2004 subid 0

En - possible values are Y, Y*, N, or N*
Y: signature is enabled
N: enabled=false in the signature definition file
*: retired=true in the signature definition file
Cmp - possible values are Y, Ni, Nr, Nf, or No
Y: signature is compiled
Ni: signature not compiled due to invalid or missing parameters
Nr: signature not compiled because it is retired
Nf: signature compile failed
No: signature is obsoleted
Action=(A)lert, (D)eny, (R)eset, Deny-(H)ost, Deny-(F)low
Trait=alert-traits EC=event-count AI=alert-interval
GST=global-summary-threshold SI=summary-interval SM=summary-mode
SW=swap-attacker-victim SFR=sig-fidelity-rating Rel=release

SigID:SubID En Cmp Action Sev Trait EC AI GST SI SM SW SFR Rel
----------- -- ---- ------ --- ----- ---- ---- ----- --- -- -- --- ---
2004:0 Y Y A HIGH 0 1 0 200 30 FA N 100 S1
sig-name: ICMP Echo Request
sig-string-info: My Sig Info
sig-comment: Sig Comment
Engine atomic-ip params:
fragment-status :
icmp-type : 8
l4-protocol : icmp
R6#

We can do a simple test by issuing a ping to 6.6.6.6 from a neighbor, R4.

Neighbor-R4#ping 6.6.6.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R4#

Now lets take a look at the console on R6. We did set the IPS to send syslog messages for alerts.

R6#
%IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:100 ICMP Echo Request [40.0.0.4:8 -> 6.6.6.6:0] VRF:NONE RiskRating:100
%IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:100 ICMP Echo Request [40.0.0.4:8 -> 6.6.6.6:0] VRF:NONE RiskRating:100
%IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:100 ICMP Echo Request [40.0.0.4:8 -> 6.6.6.6:0] VRF:NONE RiskRating:100
%IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:100 ICMP Echo Request [40.0.0.4:8 -> 6.6.6.6:0] VRF:NONE RiskRating:100
%IPS-4-SIGNATURE: Sig:2004 Subsig:0 Sev:100 ICMP Echo Request [40.0.0.4:8 -> 6.6.6.6:0] VRF:NONE RiskRating:100
R6#

Enjoy your practice, and best wishes from all of us at INE!

 

Jan
08

We are putting the final touches together for the CCSP bootcamp that is launching soon.  (PS, it is going to ROCK! :) ) As I was going through the demo’s on L2 security, I was reminded of how this topic is often an Achilles heel for many CCIE candidates, both R/S and Security.

This blog post is to refresh your memories and provide some examples  for layer 2 security on the Catalyst switch. We will begin with DHCP snooping.

I have a friend “wink, wink” who many years ago at a conference configured his Windows NT 4.0 server (ah the memories), as a DHCP server, and had almost 100  clients routing through his laptop. The only problem with this, besides really slow performance for everyone, was the fact that he was just another attendee at the conference, and was running a rogue DHCP server. Of course today, we would never allow that to happen, as we would use DHCP snooping to place all ports in an untrusted state, with the exception of the real DHCP server(s).

In the examples below, on SW1; R1, R2 and R3 are connected to ports Fa0/1, Fa0/2 and Fa0/3 respectively. R1 is the valid DHCP server, so we specify port Fa0/1 as a trusted DHCP port

DHCP snooping prevents protects against rogue servers, but it also provides another huge benefit, and that is the DHCP snooping binding table which is built dynamically and includes the clients MAC, IP, Lease time, Binding Type, VLAN# and Switch Port that client is connected to. This is huge, because now we can add on other features, like Source Guard. Source Guard uses the snooping binding table, and prevents a host from “borrowing” its neighbors IP address. If the source IP coming in on a switch port doesn’t match the IP in the binding table, the packet is dropped at the switch!

But wait, there is more. :) We have all probably heard about a L2 man in the middle attack, where the attacker poisons the arp cache of a host and it's gateway, and then eavesdrops on every frame/packet between them. Because we have the DHCP snooping table, we can stop malicious ARPs from getting into the VLAN. Once again, with ARP inspection enabled, and leveraging the snooping table, if the MAC withing the ARP doesn’t match the table, the switch kills it.

So in summary, DHCP snooping builds the binding table.  Source Guard uses the table to prevent IP address spoofing/borrowing. ARP inspection uses the table to prevent malicious/incorrect ARP packets from performing ARP cache poisoning.

The configurations, embedded notes, validations and show commands are below.

R1

!  Excluded static addresses used by R1 and SW1
ip dhcp excluded-address 123.0.0.1
ip dhcp excluded-address 123.0.0.7
ip dhcp pool MYPOOL
network 123.0.0.0 255.255.255.0
domain-name INE.com
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
! We used mac addresses that would be easily identifiable
mac-address 0011.1111.1111
! The command below allows the DHCP option inbound to server
ip dhcp relay information trusted
ip address 123.0.0.1 255.255.255.0
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
! Configured R1 as an NTP server so SW1 could have synced time
ntp master 1

R2

interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
mac-address 0022.2222.2222
ip address dhcp
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0

R3

interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
mac-address 0033.3333.3333
ip address dhcp
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0

SW1

ip dhcp snooping vlan 123
! In a production network, you would want to be careful to not exceed
! the space available in flash for storage.
ip dhcp snooping database flash:/jan7snoop.txt
ip dhcp snooping
!
ip arp inspection vlan 123
! The validate includes ARP validation for IP and source/destination MAC addresses
ip arp inspection validate ip src-mac dst-mac
!
!
interface FastEthernet0/1
Description Connection to R1, the real DHCP server
switchport access vlan 123
switchport mode access
! Because the DHCP server has a static address, there will never be
! a dynamic entry in the snooping table for R1. We could create
! and ARP access list, and use it for to compliment the dynamic table.
ip arp inspection trust
! Because R1 is a DHCP server, we have to “DHCP trust” this interface.
ip dhcp snooping trust
!
interface FastEthernet0/2
Description Connection to R2, a DHCP client
switchport access vlan 123
switchport mode access
! This next command is the Source Guard, that prevents IP Spoofing
ip verify source
!
interface FastEthernet0/3
Description Connection to R3, a DHCP client
switchport access vlan 123
switchport mode access
! This next command is the Source Guard, that prevents IP Spoofing
ip verify source

interface Vlan123
ip address 123.0.0.7 255.255.255.0
!
! When writing the DHCP snooping table to flash, the switch complains
! if it is not synchronized to an NTP server.
ntp server 123.0.0.1

So lets take a look at some show commands, first on the DHCP server R1. It shows that it handed out IP addresses via DHCP to 2 devices, using 123.0.0.6 and 123.0.0.8 (looks like someone was bringing the clients up and down a few times for testing) ☺

r1# show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
123.0.0.6 0063.6973.636f.2d30. Jan 08 2010 08:11 AM Automatic
3032.322e.3232.3232.
2e32.3232.322d.4661.
302f.30
123.0.0.8 0063.6973.636f.2d30. Jan 08 2010 08:11 AM Automatic
3033.332e.3333.3333.
2e33.3333.332d.4661.
302f.30

It looks like R1 has OSPF learned routes with next hops that match the DHCP addresses we handed out.

r1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DROTHER 00:00:33 123.0.0.6 FastEthernet0/0
3.3.3.3 1 FULL/BDR 00:00:32 123.0.0.8 FastEthernet0/0
r1# show ip route
Codes: 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

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 123.0.0.6, 00:01:21, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 123.0.0.8, 00:01:11, FastEthernet0/0
123.0.0.0/24 is subnetted, 1 subnets
C 123.0.0.0 is directly connected, FastEthernet0/0
r1#

It also appears that these 2 OSPF neighbors are in deed R2 and R3 based on the router-id.

r1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DROTHER 00:00:36 123.0.0.6 FastEthernet0/0
3.3.3.3 1 FULL/BDR 00:00:39 123.0.0.8 FastEthernet0/0
r1#

Lets jump over to SW1, and look first at the DHCP snooping binding table, to verify that it is in order.

sw1# show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:22:22:22:22:22 123.0.0.6 86053 dhcp-snooping 123 FastEthernet0/2
00:33:33:33:33:33 123.0.0.8 86062 dhcp-snooping 123 FastEthernet0/3
Total number of bindings: 2

To look at source guard, we use the following commands. Remember, source guard is leveraging the information from the DHCP snooping binding table.

sw1# show ip source binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:22:22:22:22:22 123.0.0.6 86020 dhcp-snooping 123 FastEthernet0/2
00:33:33:33:33:33 123.0.0.8 86029 dhcp-snooping 123 FastEthernet0/3
Total number of bindings: 2

sw1# show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- ----------------- ----
Fa0/2 ip active 123.0.0.6 123
Fa0/3 ip active 123.0.0.8 123

Next, lets look at some output regarding the Dynamic ARP Inspection (DAI). The only interface we trusted was Fa0/1.

sw1# show ip arp inspection interfaces

Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Fa0/1 Trusted None N/A
Fa0/2 Untrusted 15 1
Fa0/3 Untrusted 15 1
Fa0/4 Untrusted 15 1
Fa0/5 Untrusted 15 1

sw1# show ip arp inspection vlan 123

Source Mac Validation : Enabled
Destination Mac Validation : Enabled
IP Address Validation : Enabled

Vlan Configuration Operation ACL Match Static ACL
---- ------------- --------- --------- ----------
123 Enabled Active

Vlan ACL Logging DHCP Logging Probe Logging
---- ----------- ------------ -------------
123 Deny Deny Off

sw1# show ip arp inspection statistics vlan 123

Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
123 39 1 1 0

Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
123 21 0 0 0

Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data
---- ----------------- ---------------------- ---------------------
123 0 0 0
sw1#

With ARP inspection in place, lets go to R2, and view our MAC address

To begin, we have the L2 information for R1 and R3, and our own MAC address of 002.2222.2222 We can confirm this with a couple different commands.

r2# show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 123.0.0.1 8 0011.1111.1111 ARPA FastEthernet0/0
Internet 123.0.0.6 - 0022.2222.2222 ARPA FastEthernet0/0
Internet 123.0.0.8 8 0033.3333.3333 ARPA FastEthernet0/0

r2# show int fa 0/0 | inc bia
Hardware is AmdFE, address is 0022.2222.2222 (bia 000f.3431.1da0)

Now, we will change the MAC address of our Fa0/0 interface.

r2(config)#int fa 0/0
r2(config-if)#mac-address 0022.2222.2224

Lets generate an ARP request by attempting to ping a local resource that is not currently in our ARP cache.

r2(config-if)# do ping 123.0.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.0.0.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Lets see what messages are popping up on the console of SW1.

SW1

%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 123.([0022.2222.222<strong>4</strong>/123.0.0.6/0000.0000.0000/123.0.0.10/08

So the ARP never left the gate, because the MAC address that we were trying to use as part of the ARP request didn’t match the snooping table.

One last piece. Lets take a look at the Source Guard in action. R3 is directly connected to 123.0.0.0, and has routing updates for the loopback interfaces of R1 and R2 as well.

r3# show ip route
Codes: 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

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 123.0.0.1, 00:12:34, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 123.0.0.6, 00:12:34, FastEthernet0/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
123.0.0.0/24 is subnetted, 1 subnets
C 123.0.0.0 is directly connected, FastEthernet0/0
r3#

A ping to the directly connected, working OSPF neighbor 123.0.0.1 should work, right?

r3# ping 123.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
r3#

It does in fact work. Now lets source the ping from our loopback 0. If you scroll up and look at the routing table of R1, it has a route back to R3’s 3.3.3.3 as well.

r3# ping 123.0.0.1 so lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
.....
Success rate is 0 percent (0/5)
r3#

So why is this ping not working? Source guard. We are sourcing the packet from 3.3.3.3, and that doesn’t match the snooping table, and so the switch rejects it. To do a quick verification, we can remove the source guard from the switch port that R3 is connected to, and try it again.

sw1(config)#int fa 0/3
sw1(config-if)#no ip verify source

And now, drum roll please, the ping.

r3#ping 123.0.0.1 so lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.0.0.1, 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 = 1/2/4 ms
r3#

Remember, if we aren’t using DHCP in our network, and still want to use these features, we can create manual snooping and arp inspection entries, and get the same effect. Our workbooks have extensive examples and explanations.

The transparent mode ASA firewall, has it’s own set of tricks for L2 security as well, and we’ll leave that for another day.

Best wishes from the INE team!

Jan
05

Feeling smart? :)   Give these Security CCIE core knowledge questions a try.  Click here for part 3 of this series.

Let us know what you feel the answers are, and good luck!

Implement Identity Management
Based on the example below, what commands will bob have the ability to use within the IOS?

enable secret cisco
username bob password cisco
username bob privilege 15
aaa new-model
aaa authentication login default group tacacs
aaa authorization config-commands
aaa authorization commands 0 default group tacacs+ local
aaa authorization commands 1 default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local
tacacs-server host 10.1.1.1
tacacs-server key cisco123

Implement secure networks using ASA Firewalls
When using SSH to connect to an ASA running in multiple mode, the changeto command does not work for one of the administrators. What would cause this?

Implement secure networks using IOS Firewalls
When is a standard IOS IP ACL used to identify a destination?

Configure advanced security
What does the "fragment" option mean when used with an ACE?

Best of luck!

Dec
31

Benjamin Franklin was quoted as saying "You may delay but time will not".  We may also say that "Email may tolerate delay, but VOIP will not".  Performance Routing (PfR), previously called Optimized Edge Routing (OER), is designed to solve network performance issues, such as delay, that vanilla IP routing can’t.  In this blog, we will use the term OER as that is still the command set used.

Petr and the team have created some awesome new labs on OER, including Volume 1, v5 in the IP Routing section. Our workbook content is extensive, has great explanations for everything and is highly recommended it to anyone preparing for the v4 CCIE RS lab.

One of the big challenges for the OER newcomer is knowing what to expect after configuring OER, and how to see measurable results. My intention in this blog post, is to assist the learner by providing a jump start into OER/PfR, by walking you through a solid configuration, and sharing a few critical show and debug commands to verify that OER is working. For you dynamips/GNS3 fans, the configuration may be replicated using (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T10, RELEASE SOFTWARE (fc3).

So, how does it work?   It is actually very simple.  In the world of OER, there are 2 roles. The brains of the operation, called the master controller, and the border router who owns the exit interfaces. There may be multiple border routers. The key is there needs to be at least 2 or more exit points across the borders being managed by a single controller. Although the controller and border can actually run on the same router, I broke it up into separate devices for this blog post. R1 will be the OER Master Controller, and R2 will be the OER Border. Here is the topology.

Single Border, with 2 exit interfaces.

First we will create key chain on the controller R1.  The key is used for communications between the controller and the border.

R1(config)# key chain cisco
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string cisco

Next, on R1 we will configure the master controller portion. About 98 % of all the configuration for OER is done on the controller. Here we will enable logging, and specify who the border(s) are, along with which interfaces on the border are exit interfaces to the outside world.

R1(config)#oer master
R1(config-oer-mc)#logging
R1(config-oer-mc)#border 136.1.12.2 key-chain cisco
R1(config-oer-mc-br)#interface Tunnel1 external
R1(config-oer-mc-br-if)#interface Tunnel2 external
R1(config-oer-mc-br-if)#interface FastEthernet0/0 internal
R1(config-oer-mc-br)#exit

Next on the controller, we  specify that we will learn prefixes based on throughput and delay, set time periods regarding learning, and tell the controller the network lengths to learn. In this example, due to the small network, we are going to have the controller learn /32 routes. We could also specify a maximum number of prefixes to learn as well. (Note: In a production network, you would not want thousands of static routes for sites visited by users. There is a default maximum, and the default aggregation is /24).

R1(config-oer-mc)#learn
R1(config-oer-mc-learn)#throughput
R1(config-oer-mc-learn)#delay
R1(config-oer-mc-learn)#periodic-interval 1
R1(config-oer-mc-learn)#monitor-period 2
R1(config-oer-mc-learn)#expire after time 30
R1(config-oer-mc-learn)#aggregation-type prefix-length 32
R1(config-oer-mc-learn)#exit

Next, now that we have exited out of “learn mode”, we can configure some of the other properties of the controller, such as how often to make prefix decisions (the backoff period), allow it to put routes in the routing table (mode route control), and choose the best exit interface (mode select-exit best). OER will create /32 static routes that use that use the “best” interface to reach the destination network.

R1(config-oer-mc)#backoff 180 360
R1(config-oer-mc)#mode route control
R1(config-oer-mc)#mode select-exit best

A few additional options include how often to make policy decisions, (periodic command), and which policy items are the most important regarding making those policy decisions (resolve commands).  Highest priority is 1, and lowest is 10.

R1(config-oer-mc)#periodic 90
R1(config-oer-mc)#resolve loss priority 1 variance 1
R1(config-oer-mc)#resolve delay priority 2 variance 1
R1(config-oer-mc)#resolve utilization priority 3 variance 1
R1(config-oer-mc)#resolve range priority 4

That is it for now on the controller. Let’s visit the border router R2 next. We’ll create the key chain, and tell R2 who the controller is. We will also tell R2 which interface to use for sending an active probe, (in the event the controller requests one).  Active probes are one method (from many available within OER) to determine delay.

R2(config)# key chain cisco
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string cisco

R2(config)#oer border
R2(config-oer-br)#local FastEthernet0/0
R2(config-oer-br)#master 136.1.12.1 key-chain cisco
R2(config-oer-br)#active-probe address source interface Loopback0

So, how do we verify this? Since we are at R2, let’s start by issuing a show oer border on R2.

R2#show oer border
OER BR 136.1.12.2 ACTIVE, MC 136.1.12.1 UP/DOWN: UP 00:00:03,
Auth Failures: 0
Conn Status: SUCCESS, PORT: 3949
Version: 2.1 MC Version: 2.1
Exits
Fa0/0 INTERNAL Tu1 EXTERNAL Tu2 EXTERNAL
R2#

From this we see that we have successfully connected with the controller (R1), and that the controller has told R2 which interfaces are internal and which are external, based on what we configured on R1.

On R1, we can issue a few commands to confirm our configuration and connectivity to our border as well. Any elements shown in the output that we didn’t configure are based on the default settings.   Lets jump over to R1 and take a look.

R1#show oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Version: 2.1
Number of Border routers: 1 Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0

Border Status UP/DOWN AuthFail Version 136.1.12.2 ACTIVE UP 00:00:12 0 2.1
! Note: Below, items in bold are derived from our configuration.
Global Settings:
max-range-utilization percent 0 recv 0
mode route metric bgp local-pref 5000
mode route metric static tag 5000
trace probe delay 1000
logging

Default Policy Settings:
backoff 180 360 180
delay relative 50
holddown 300
periodic 90
probe frequency 56
mode route control
mode monitor both
mode select-exit best
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve loss priority 1 variance 1 resolve delay priority 2 variance 1 resolve utilization priority 3 variance 1 resolve range priority 4 variance 0

Learn Settings:
current state : RETRY
time remaining in current state : 26 seconds
throughput delay
no inside bgp
no protocol
monitor-period 2 periodic-interval 1
aggregation-type prefix-length 32
prefixes 200
expire after time 30
R1#

As a reference below, on R2, here are the IP addresses and Interfaces in use.   Note, that Serial 0/0 is used only as a transport for the GRE tunnels.

R2#show ip int brief | ex una
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 136.1.12.2 YES NVRAM up up
Serial0/0 136.1.23.2 YES NVRAM up up
Loopback0 150.1.2.2 YES NVRAM up up
Tunnel1 10.0.0.2 YES NVRAM up up
Tunnel2 20.0.0.2 YES NVRAM up up
R2#

Here is the initial routing table on R2, (before OER has dynamically learned routes). We have only 2 static routes, which originated from the startup configuration.

R2#show ip route
Codes: 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

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0

20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2

10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1

150.1.0.0/24 is subnetted, 1 subnets
C 150.1.2.0 is directly connected, Loopback0

S* 0.0.0.0/0 [1/0] via 20.0.0.3 [1/0] via 10.0.0.3
R2#

R2#show run | inc route
ip route 0.0.0.0 0.0.0.0 10.0.0.3 ip route 0.0.0.0 0.0.0.0 20.0.0.3

Now for the fun part. (Really!:) Lets generate some traffic in the background, and allow OER to dynamically learn the specific routes, as well as learn the best path to those routes and watch those routes be added to the routing table on R2. We’ll create two SLAs from R1 directed to the loopbacks of R4 and R5.

R1

R1(config)#ip sla 1
R1(config-ip-sla)#tcp-connect 150.1.4.4 4000
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla schedule 1 life forever start-time now
R1(config)#
R1(config)#ip sla 2
R1(config-ip-sla)#tcp-connect 150.1.5.5 5000
R1(config-ip-sla-tcp)#timeout 100
R1(config-ip-sla-tcp)#frequency 1
R1(config-ip-sla-tcp)#exit
R1(config)#ip sla schedule 2 life forever start-time now

On R4 and R5, we need to set up the SLA responder, so they will respond correctly to the tcp-connect requests sourced from R1.

R4 and R5

R4(config)#ip sla responder
R5(config)#ip sla responder

On R2, lets see what networks have been learned. (Note: Based on the timers, it may take a ~minute or so for the /32 networks of 150.1.4.4 and 150.1.5.5 to be learned.   I waited at least a couple minutes before issuing the commands below.   You may want to verify that your SLA traffic is reaching R4 and R5 if you need to troubleshoot).

R2#show oer border passive cache prefix

OER Passive Prefix Cache, State: enabled, 278544 bytes
4 active, 4092 inactive, 1222 added
67316 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 25800 bytes
12 active, 1012 inactive, 3666 added, 1222 added to flow
0 alloc failures, 0 force free
1 chunk, 30 chunks added
0 flows not aggregated due to main subcache starvation

Prefix NextHop Src If Dst If Flows
Pkts B/Pk Active sDly #Dly PktLos #UnRch
------------------------------------------------------------------------
150.1.4.4/32 0.0.0.0 Tu1 Fa0/0 24
34 38 18.5 0 0 0 0
150.1.5.5/32 0.0.0.0 Tu1 Fa0/0 24
34 38 18.1 0 0 0 0
150.1.4.4/32 20.0.0.3 Fa0/0 Tu2 23
35 62 18.5 64 5 0 0
150.1.5.5/32 20.0.0.3 Fa0/0 Tu2 23
35 62 18.1 84 5 0 0
R2#

Now, lets turn on a debug of active probes on the border, and see what we can learn from it.

R2#debug oer border active-probes detail
<snip>
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 339 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 2, Sum of rtt 40, Max rtt 24, Min rtt 16
<snip>
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 340 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 2, Sum of rtt 52, Max rtt 28, Min rtt 24

Based on this, the rtt values from Tunnel 1 (using 10.0.0.3 as the next hop to reach 150.1.4.4) are lower than Tunnel 2 (which is using 20.0.0.3 as the next hop). As a result, OER believes that Tunnel 1 is the best path and will inject a static /32 route for destination 150.1.4.4, using Tunnel 1 as the exit interface and 10.0.0.3 as the next hop. A similar result was discovered for 150.1.5.5 as well. As a result, both /32 routes are dynamically added to the routing table on R2.

R2#show ip route
Codes: 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

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0
20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1
150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 150.1.2.0/24 is directly connected, Loopback0
! OER dynamically added the 2 static routes below
S 150.1.5.5/32 [1/0] via 10.0.0.3 S 150.1.4.4/32 [1/0] via 10.0.0.3
S* 0.0.0.0/0 [1/0] via 20.0.0.3
[1/0] via 10.0.0.3
R2#

Also, on R1, the controller, there were a couple messages logged:

%OER_MC-5-NOTICE: Route changed Prefix 150.1.5.5/32, BR 136.1.12.2, i/f Tu1, Reason Delay, OOP Reason Timer Expired
%OER_MC-5-NOTICE: Route changed Prefix 150.1.4.4/32, BR 136.1.12.2, i/f Tu1, Reason Delay, OOP Reason Timer Expired

So now that OER has decided that Tunnel 1, using 10.0.0.3 is the best path for those 2 networks, lets tip the scale in the other direction by using generic  traffic shaping on Tunnel 1, so that the delay there will be worse than Tunnel 2, and watch the results. (Note: in addition to the generic traffic shaping on R2 Tunnel 1, I also ran an extended ping sourced from 150.1.4.4 and 150.1.5.5 to increase the overall delay).

R2(config-if)#traffic-shape rate 8000 1000 0
R2(config-if)#do show traffic-shape

Interface Tu1
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 8000 125 1000 0 125 125 -

R2#
! Below is debug output showing Tunnel 2 with next hop of 20.0.0.3 ! as having the least delay for destination 150.1.4.4 ...

OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 363 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 88, Max rtt 88, Min rtt 88
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.4.4, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 364 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 8, Max rtt 8, Min rtt 8
OER BR APE detail: Completed retrieving Probe Statistics.

! Now the debug output for the destination 150.1.5.5 showing ! that Tunnel 2 with next hop of 20.0.0.3 has the least delay ....
probeType = echo, probeTarget = 150.1.5.5, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 10.0.0.3
probeIfIndex = 10, SAA index = 365 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 72, Max rtt 72, Min rtt 72
OER BR APE detail: Completed retrieving Probe Statistics.
probeType = echo, probeTarget = 150.1.5.5, probeTargetPort = 0
probeSource = 150.1.2.2, probeSourcePort = 0, probeNextHop = 20.0.0.3
probeIfIndex = 11, SAA index = 366 probeToS = 0 policy_seq = 0
OER BR APE detail: Completions 1, Sum of rtt 12, Max rtt 12, Min rtt 12

Back on the master controller (R1), we notice the messages:

%OER_MC-5-NOTICE: Route changed Prefix 150.1.4.4/32, BR 136.1.12.2, i/f Tu2, Reason Delay, OOP Reason Timer Expired
%OER_MC-5-NOTICE: Route changed Prefix 150.1.5.5/32, BR 136.1.12.2, i/f Tu2, Reason Delay, OOP Reason Timer Expired

On R2 (the border), here is the updated routing table:

R2#show ip route
Codes: 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

Gateway of last resort is 20.0.0.3 to network 0.0.0.0

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
C 136.1.23.0 is directly connected, Serial0/0

20.0.0.0/24 is subnetted, 1 subnets
C 20.0.0.0 is directly connected, Tunnel2

10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel1

150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 150.1.2.0/24 is directly connected, Loopback0

! Note: the next hop has changed, and will use Tunnel 2 as the exit
S 150.1.5.5/32 [1/0] via 20.0.0.3
S 150.1.4.4/32 [1/0] via 20.0.0.3

S* 0.0.0.0/0 [1/0] via 20.0.0.3
[1/0] via 10.0.0.3
R2#

For detailed information regarding OER and the hundreds of options available with it, please leverage the content in our updated V5 RS content.

OER is very fun, and very important. Enjoy your studies, and good luck!

 

Dec
28

What does RITE and the v4 CCIE blueprint have in common? Section 10.04 :) If you are new to RITE, or would like to know more about it, read on.

Router IP Traffic Export, (RITE), allows the forwarding of unaltered IP packets from a router interface to memory or to a specific MAC address on a locally attached network. A likely candidate being the MAC address of a network analyzer or Intrusion Detection System.

As an example, lets configure RITE on R2. Setting it up is simple. We first create a profile, and apply that profile to an interface. But what if we don't want to export all of the traffic? No problem. We can also filter to specify exactly which traffic should be captured and exported, and we can even specify a smaller sample of the overall traffic flow if desired.

In this example, we will create an access-list that only matches if the source traffic is from R5’s loopback 0 address of 150.1.5.5

R2:

ip access-list extended FROM-R5
permit ip host 150.1.5.5 any

Next lets create a simple profile, (we will call this one “R5”), and specify the interface where we will export the packets to, as well as the MAC address that is reachable locally by R2. We will also leverage the access-list to filter on what may be captured, as well as a sampling rate of 1 in every 5 packets, (20%).

R2:

ip traffic-export profile R5
interface FastEthernet0/0
incoming access-list FROM-R5
mac-address 0123.4567.89ab
incoming sample one-in-every 5
exit

Next we will apply the profile to the interface which will be receiving the packets sourced from R5 loopback 0.

R2

interface Serial0/0
ip traffic-export apply R5

Turning on debugging will assist in seeing the activity behind the scene.

R2:

debug ip traffic-export events

Next, we generate some traffic, sourced from R5 loopback 0. This traffic does pass through the serial 0/0 interface of R2.

R5:

R5#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM up up
Serial0/0 unassigned YES NVRAM administratively down down
FastEthernet0/1 136.1.45.5 YES NVRAM up up
Serial0/1 unassigned YES NVRAM administratively down down
Loopback0 150.1.5.5 YES NVRAM up up

R5#
R5#ping 150.1.2.2 repeat 50 source loopback 0

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.5.5
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 4/12/32 ms
R5#

Back to R2, to see the results of the debug.

R2#RITE: exported input packet # 1
RITE: exported input packet # 2
RITE: exported input packet # 3
RITE: exported input packet # 4
RITE: exported input packet # 5
RITE: exported input packet # 6
RITE: exported input packet # 7
RITE: exported input packet # 8
RITE: exported input packet # 9
RITE: exported input packet # 10

R2#

Now lets look at some of the statistics.

R2#show ip traffic-export
Router IP Traffic Export Parameters
Monitored Interface Serial0/0
Export Interface FastEthernet0/0
Destination MAC address 0123.4567.89ab
bi-directional traffic export is off
Input IP Traffic Export Information Packets/Bytes Exported 10/1000
Packets Dropped 43
Sampling Rate one-in-every 5 packets
Access List FROM-R5 [named extended IP]
Profile R5 is Active
R2#

Out of the 50 pings, 10 of them were exported, due to the profile we created. The packets dropped reflect packets that were not exported, including 40 from R5, and 3 other packets that did not match the ACL in the profile.

Keep up the great studies, and good luck!

Dec
17

Using an IPS Sensor, we can dynamically apply rate limiting/policing on a router interface, based on a signature match or an event action over-ride, which is generated on the sensor appliance.   Ok, I know there is no Sensor Appliance in the RS lab, but what if we need to trigger a rate limit of specific traffic, destined to a router, based on current conditions on that router, such as transmit or receive loads on an interface.

This is a job for, da dada dahhh: Embedded Event Manager (EEM).  In this example we will create a service policy which we will apply to the control plane based on a interface threshold being exceeded.  Full labs on Embedded Event Manager can be found in our RS v5 Vol1 workbook in  "System Management".  Let's break down the individual steps, first for the control plane policing policy, and then the EEM to apply it.

We will first create a policy map, which calls on a class map, which calls on an ACL. In this class map, we are going to identify ICMP, by referencing an access list. So first we create the access list, and we will name it ICMP.

ip access-list extended ICMP
permit icmp any any

Now that the access list is created, we will create the class map called ICMP which will be referencing the access list of the same name.

class-map match-all ICMP
match access-group name ICMP
exit

Next we will create the policy map, and for convenience we will name it ICMP (as well). This policy map will reference the class map, and specify  policing at 8000 bits per second with a burst rate of 1000 bytes.

policy-map ICMP
class ICMP
police 8000 1000

Ok, so now for the EEM part of the configuration.  First, we will create our event manager applet. In this applet we will be referencing serial 0/0, and we will be looking for the received load to be greater than 25. The 25 refers to 25 out of a possible 255 as reported by the interface. Once the ~10% is exceeded, the CLI commands implemented in our applet will be executed. The CLI commands will simply apply the service policy to the logical control plane host interface on the router. By doing this, any ICMP traffic destined TO the router, will be policed, regardless of which interface the traffic is received on.   The EEM policy will also generate a syslog message. There are additional options which we could include, such as sending SNMP traps, e-mail messages and so forth.

event manager applet LOAD
event interface name Serial0/0 parameter rxload entry-val 25 entry-op gt entry-val-is-increment false poll-interval 60
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "control-plane host"
action 3.0 cli command "service-policy input ICMP"
action 4.0 syslog msg "Just Applied Control Plane Policy to Limit ICMP"
exit

At the interface level we will specify a bandwidth statement of 64, which will allow us to trigger the 25/255 much quicker. We will also set the load interval to a lower value than the default of five minutes so that the average will increase faster.

interface ser 0/0
bandwidth 64
load-interval 30
end

The following debug, will give us the Howard Cosell play-by-play of exactly what's happening.

R2#debug event manager action cli
Debug EEM action cli debugging is on

To view the details of the interfaces that are registered with an event manager policy, we would use the following show command.

R2#show event manager policy registered event-type interface
No. Class Type Event Type Trap Time Registered Name
1 applet user interface Off Thu Feb 28 18:51:41 2002 LOAD
name {Serial0/0} parameter {rxload} entry_op gt entry_val 25 entry_val_is_increment FALSE poll_interval 60.000
maxrun 20.000
action 0.0 cli command "enable"
action 1.0 cli command "configure terminal"
action 2.0 cli command "control-plane host"
action 3.0 cli command "service-policy input ICMP"
action 4.0 syslog msg "Just Applied Control Plane Policy to Limit ICMP"

To verify what the current load is on the interface, we can use the command below.

R2#show int ser 0/0 | inc rxload
reliability 255/255, txload 1/255, rxload 1/255

Once the control plane policy has been applied, the actual details of how many packets have been permitted and denied by that policy will be shown by the command below.

R2#show policy-map control-plane host
R2#

From the commands above, you'll notice that the current load is at one, and there is no policy currently applied to the control plane. Let's go to the neighboring router and generate some traffic to trigger event manager and the applet that we just created.

Neighbor-R3#ping 150.1.2.2 size 500 repeat 1000 timeout 0

Type escape sequence to abort.
Sending 1000, 500-byte ICMP Echos to 150.1.2.2, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
.......................................................!.!............
......................................................................
.............................................!........................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
....................
Success rate is 0 percent (3/1000), round-trip min/avg/max = 4/6/8 ms
Neighbor-R3#

Cool, we got 3 back, even with a timeout of 0 seconds.  Now lets go back to R2, and look at some results.

R2#show int ser 0/0 | inc rxload
reliability 255/255, txload 58/255, rxload 58/255
R2#
! Note: It may take a few moments for the policy as polling occurs every 60 seconds ! ! Patience is a virtue, and I want mine NOW ;-) !

%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : CTL : cli_open called.
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2#enable
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2#configure terminal
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config)#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2(config)#control-plane host
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config-cp-host)#
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : IN : R2(config-cp-host)#service-policy input ICMP
%CP-5-FEATURE: Control-plane Policing feature enabled on Control plane host path

%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : OUT : R2(config-cp-host)#
%HA_EM-6-LOG: LOAD: Just Applied Control Plane Policy to Limit ICMP
%HA_EM-6-LOG: LOAD : DEBUG(cli_lib) : : CTL : cli_close called.
R2#
%SYS-5-CONFIG_I: Configured from console by vty0
R2#

Back to the neighbor router, R3 to see how the policing of ICMP looks from the outside.

Neighbor-R3#ping 150.1.2.2 size 500 repeat 20         

Type escape sequence to abort.
Sending 20, 500-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!!.!!.!!.!!.!!.!!.!.
Success rate is 65 percent (13/20), round-trip min/avg/max = 4/12/24 ms
Neighbor-R3#

Back to R2 to view the output of the service policy.

R2#show policy-map control-plane host
Control Plane Host

Service-policy input: ICMP

Class-map: ICMP (match-all)
20 packets, 10080 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name ICMP
police:
cir 8000 bps, bc 1000 bytes
conformed 13 packets, 6552 bytes; actions:
transmit
exceeded 7 packets, 3528 bytes; actions:
drop
conformed 0 bps, exceed 0 bps

Class-map: class-default (match-any)
3 packets, 268 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
R2#

Based on results, the service policy is now applied to the control-plane host sub-interface, and is limiting ICMP.  This example of EEM is like a single ice-cube, compared to a titanic sized iceberg of possibilities.   My intention is to introduce the topic, and encourage you to study it further.

I configured this demonstration using IOS Version 12.4(15)T10

Enjoy your studies, and have fun exploring the world of EEM.

Dec
07

Cheers from London! I learned this week that a "Christmas Cracker" is not a food item, OR a person.  ;-)    There is so much to know.  I am grateful for students willing to show me the ropes here in the UK.   Thank you all.    Now on to the topic at hand.

MPLS is an important part of the RS Bootcamp, including troubleshooting MPLS.

Here is an MPLS troubleshooting scenario, that has 1 (one,одну,un,uno) configuration issue.  Can you spot it?  Lets get to it!  Here is the diagram.

mpls-ine-blog

Problem: Clients on the 5.5.5.0 network are not able to ping the server, or any other devices, on the 1.1.1.0 network. Your challenge, based on the provided IOS show commands only, is to identify the 1 configuration problem that is causing the network failure.

For this scenario, the PC and Server configurations are correct, as well as all the layer 2 switching infrastructure on the Catalyst switches. R1 and R5 are CE routers, R2 and R4 are PE routers, and R3 is a P router.

We will work from the diagram, using the show commands from right to left, starting with R5.    (I have grouped the show commands together, then the individual commands and their output.   This way, the post may be used as a study/reference tool.)

R5
show ip int brief | ex una
show ip route
show ip protocols
ping 136.1.45.255

R5#show ip int brief | ex una
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 5.5.5.5 YES manual up up
FastEthernet0/1 136.1.45.5 YES NVRAM up up
Loopback0 150.1.5.5 YES NVRAM up up
R5#show ip route
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
R 136.1.12.0 [120/1] via 136.1.45.4, 00:00:08, FastEthernet0/1
C 136.1.45.0 is directly connected, FastEthernet0/1
1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 136.1.45.4, 00:00:08, FastEthernet0/1
5.0.0.0/24 is subnetted, 1 subnets
C 5.5.5.0 is directly connected, FastEthernet0/0
150.1.0.0/24 is subnetted, 1 subnets
C 150.1.5.0 is directly connected, Loopback0
R5#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 11 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
FastEthernet0/0 2 2
FastEthernet0/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
136.1.0.0
Routing Information Sources:
Gateway Distance Last Update
136.1.45.4 120 00:00:08
Distance: (default is 120)

R5#ping 136.1.45.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.45.255, timeout is 2 seconds:

Reply to request 0 from 136.1.45.4, 8 ms
Reply to request 1 from 136.1.45.4, 32 ms
Reply to request 2 from 136.1.45.4, 16 ms
Reply to request 3 from 136.1.45.4, 4 ms
Reply to request 4 from 136.1.45.4, 24 ms
R5#

R4
show ip route
show ip route vrf Vrf1
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table
show ip bgp summary
show ip bgp vpnv4 all
ping vrf Vrf1 136.1.45.255
ping 136.1.34.255

R4#show ip route
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
O 136.1.23.0 [110/65] via 136.1.34.3, 00:04:28, FastEthernet0/0
C 136.1.34.0 is directly connected, FastEthernet0/0
150.1.0.0/32 is subnetted, 2 subnets
C 150.1.4.4 is directly connected, Loopback0
O 150.1.2.2 [110/66] via 136.1.34.3, 00:04:28, FastEthernet0/0
R4#show ip route vrf Vrf1

Routing Table: Vrf1
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
B 136.1.12.0 [200/0] via 150.1.2.2, 00:04:23
C 136.1.45.0 is directly connected, FastEthernet0/1
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [200/2] via 150.1.2.2, 00:04:23
5.0.0.0/24 is subnetted, 1 subnets
R 5.5.5.0 [120/1] via 136.1.45.5, 00:00:01, FastEthernet0/1
R4#show ip protocols
Routing Protocol is "ospf 234"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 150.1.4.4
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
FastEthernet0/0
Loopback0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
150.1.2.2 110 00:04:28
150.1.3.3 110 00:04:28
Distance: (default is 110)

Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 0 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)

Routing Protocol is "bgp 24"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
150.1.2.2
Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
Distance: external 20 internal 200 local 200

R4#show mpls interface
Interface IP Tunnel Operational
FastEthernet0/0 Yes (ldp) No Yes
R4#show mpls ldp neighbor

R4#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 150.1.2.2/32 0 Fa0/0 136.1.34.3
18 Untagged 136.1.23.0/24 0 Fa0/0 136.1.34.3
19 Untagged 5.5.5.0/24[V] 19950 Fa0/1 136.1.45.5
20 Aggregate 136.1.45.0/24[V] 1684
R4#show ip bgp summary
BGP router identifier 150.1.4.4, local AS number 24
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
150.1.2.2 4 24 148 149 1 0 0 02:08:57 0
R4#show ip bgp vpnv4 all
BGP table version is 22, local router ID is 150.1.4.4
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
Route Distinguisher: 1:1 (default for vrf Vrf1)
*>i1.1.1.0/24 150.1.2.2 2 100 0 ?
*> 5.5.5.0/24 136.1.45.5 1 32768 ?
*>i136.1.12.0/24 150.1.2.2 0 100 0 ?
*> 136.1.45.0/24 0.0.0.0 0 32768 ?
R4#ping vrf Vrf1 136.1.45.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.45.255, timeout is 2 seconds:

Reply to request 0 from 136.1.45.5, 4 ms
Reply to request 1 from 136.1.45.5, 28 ms
Reply to request 2 from 136.1.45.5, 16 ms
Reply to request 3 from 136.1.45.5, 32 ms
Reply to request 4 from 136.1.45.5, 8 ms
R4#ping 136.1.34.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.34.255, timeout is 2 seconds:

Reply to request 0 from 136.1.34.3, 8 ms
Reply to request 1 from 136.1.34.3, 4 ms
Reply to request 2 from 136.1.34.3, 16 ms
Reply to request 3 from 136.1.34.3, 8 ms
Reply to request 4 from 136.1.34.3, 4 ms
R4#

R3
show ip route
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table

R3#show ip route
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.23.0 is directly connected, Serial0/0.23
C 136.1.34.0 is directly connected, FastEthernet0/0
150.1.0.0/32 is subnetted, 3 subnets
O 150.1.4.4 [110/2] via 136.1.34.4, 00:05:16, FastEthernet0/0
C 150.1.3.3 is directly connected, Loopback0
O 150.1.2.2 [110/65] via 136.1.23.2, 00:05:26, Serial0/0.23
R3#show ip protocols
Routing Protocol is "ospf 234"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 150.1.3.3
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
FastEthernet0/0
Serial0/0.23
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
150.1.4.4 110 00:05:16
150.1.2.2 110 00:05:26
Distance: (default is 110)

R3#show mpls interface
Interface IP Tunnel Operational
FastEthernet0/0 Yes (ldp) No Yes
Serial0/0.23 Yes (ldp) No Yes
R3#show mpls ldp neighbor

R3#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged 150.1.2.2/32 0 Se0/0.23 point2point
17 Untagged 150.1.4.4/32 0 Fa0/0 136.1.34.4

R2
show ip route
show ip route vrf Vrf1
show ip protocols
show mpls interface
show mpls ldp neighbor
show mpls forwarding-table
show ip bgp summary
show ip bgp vpnv4 all
ping 136.1.23.255
ping vrf Vrf1 136.1.12.255

R2#show ip route
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.23.0 is directly connected, Serial0/0.23
O 136.1.34.0 [110/65] via 136.1.23.3, 00:05:41, Serial0/0.23
150.1.0.0/32 is subnetted, 2 subnets
O 150.1.4.4 [110/66] via 136.1.23.3, 00:05:41, Serial0/0.23
C 150.1.2.2 is directly connected, Loopback0
R2#show ip route vrf Vrf1

Routing Table: Vrf1
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
B 136.1.45.0 [200/0] via 150.1.4.4, 00:05:18
1.0.0.0/24 is subnetted, 1 subnets
O 1.1.1.0 [110/2] via 136.1.12.1, 02:18:47, FastEthernet0/0
5.0.0.0/24 is subnetted, 1 subnets
B 5.5.5.0 [200/1] via 150.1.4.4, 00:05:18
R2#show ip protocols
Routing Protocol is "ospf 234"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 150.1.2.2
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing on Interfaces Configured Explicitly (Area 0):
Serial0/0.23
Loopback0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
150.1.4.4 110 00:05:41
150.1.3.3 110 00:05:51
Distance: (default is 110)

Routing Protocol is "bgp 24"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
IGP synchronization is disabled
Automatic route summarization is disabled
Neighbor(s):
Address FiltIn FiltOut DistIn DistOut Weight RouteMap
150.1.4.4
Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
Distance: external 20 internal 200 local 200

R2#show mpls interface
Interface IP Tunnel Operational
Serial0/0.23 Yes (ldp) No Yes
R2#show mpls ldp neighbor

R2#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 136.1.34.0/24 0 Se0/0.23 point2point
18 Untagged 150.1.4.4/32 0 Se0/0.23 point2point
21 Aggregate 136.1.12.0/24[V] 1040
22 Untagged 1.1.1.0/24[V] 18240 Fa0/0 136.1.12.1
R2#show ip bgp summary
BGP router identifier 150.1.2.2, local AS number 24
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
150.1.4.4 4 24 151 150 1 0 0 02:10:15 0
R2#show ip bgp vpnv4 all
BGP table version is 13, local router ID is 150.1.2.2
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
Route Distinguisher: 1:1 (default for vrf Vrf1)
*> 1.1.1.0/24 136.1.12.1 2 32768 ?
*>i5.5.5.0/24 150.1.4.4 1 100 0 ?
*> 136.1.12.0/24 0.0.0.0 0 32768 ?
*>i136.1.45.0/24 150.1.4.4 0 100 0 ?
R2#ping 136.1.23.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.23.255, timeout is 2 seconds:

Reply to request 0 from 136.1.23.3, 12 ms
Reply to request 1 from 136.1.23.3, 16 ms
Reply to request 2 from 136.1.23.3, 32 ms
Reply to request 3 from 136.1.23.3, 28 ms
Reply to request 4 from 136.1.23.3, 28 ms
R2#ping vrf Vrf1 136.1.12.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.12.255, timeout is 2 seconds:

Reply to request 0 from 136.1.12.1, 4 ms
Reply to request 1 from 136.1.12.1, 28 ms
Reply to request 2 from 136.1.12.1, 16 ms
Reply to request 3 from 136.1.12.1, 28 ms
Reply to request 4 from 136.1.12.1, 12 ms
R2#

R1
show ip int brief | ex una
show ip route
show ip protocols
ping 136.1.12.255

R1#show ip int brief | ex una
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 136.1.12.1 YES NVRAM up up
FastEthernet0/1 1.1.1.1 YES manual up up
Loopback0 150.1.1.1 YES NVRAM up up
R1#show ip route
Codes: 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

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 2 subnets
C 136.1.12.0 is directly connected, FastEthernet0/0
O E2 136.1.45.0 [110/1] via 136.1.12.2, 00:06:20, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/1
5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [110/1] via 136.1.12.2, 00:06:20, FastEthernet0/0
150.1.0.0/24 is subnetted, 1 subnets
C 150.1.1.0 is directly connected, Loopback0
R1#show ip protocols
Routing Protocol is "ospf 12"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 150.1.1.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
1.1.1.0 0.0.0.255 area 0
136.1.12.1 0.0.0.0 area 0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
136.1.12.2 110 00:06:20
Distance: (default is 110)

R1#ping 136.1.12.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.12.255, timeout is 2 seconds:

Reply to request 0 from 136.1.12.2, 8 ms
Reply to request 1 from 136.1.12.2, 20 ms
Reply to request 2 from 136.1.12.2, 12 ms
Reply to request 3 from 136.1.12.2, 24 ms
Reply to request 4 from 136.1.12.2, 8 ms
R1#

What do you see as the problem, and what may be done to correct it?

Good luck!

Nov
24

For Part 2 of this series, click here.

The following questions will be added to the Core Knowledge Simulation engine.   Answers will be provided in the comments section.

Implement Identity Management

Refer to the diagram.   The software running on the PC performs what role?

Basic 802.1x

Configure Cisco IPS to mitigate network threats

Refer to the diagram.   How are IPS alerts from the IOS router collected on IME and MARS?

IOS IPS

Implement secure networks using Cisco ASA Firewalls

When a new policy-map is applied globally, what effect does that have on the interfaces of the ASA?

Implement secure networks using Cisco VPN solutions

What layer 4 ports / protocols would  typically be used as part of a GDOI implementation?

Nov
20

Every once in a while I come across a tip that is so exciting I want to share it with the world. I was recently going through one of the many posts I read, and saw the answer to a question that I have been wondering about for many years. Awesome job to Steve Shaw who came up with this. Here is the scenario. We are running EIGRP, and have a neighbor, but no console access to that neighbor. We get the message on our local router saying “%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor A.B.C.D (Fa0/1) is down: K-value mismatch”.

Now for the tricky part. There are 5 K values, each K value supporting a value between 0-255 inclusive.  It would take a long time to test all of the possible values of K1-K5 until we “crack the code” and get the right values.

Here is a solution to discover which K values are in use on the remote neighbor. Locally, create an access-list to match on EIGRP updates:

access-list 100 permit ip host 136.1.45.4 host 224.0.0.10

Be sure to pick a free ACL #. For the source address, use the IP address of the neighbor.

Then use the following debug command:

debug ip packet 100 detail dump

Context sensitive help may not show the "dump" keyword as an option at the end, but it is most likely still available.  Make sure to log to a location where the output of the debug may be seen, such as the buffer, console or a syslog server.

If our neighbor has K values of:
EIGRP metric weight K1=1, K2=1, K3=1, K4=1, K5=1
On our local router we would should see the debug output similar to this:

01:04:28: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
0F4019C0: 0100 5E00000A ..^...
0F4019D0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
0F4019E0: 0158239B 88012D04 E000000A 0205EDC9 .X#...-.`.....mI
0F4019F0: 00000000 00000000 00000000 00000001 ................
0F401A00: 0001000C 01010101 0100000F 00040008 ................
0F401A10: 0C040102 ....

The 16th byte from the end (or the 4th grouping from the end), is where the K values begin. The K values are in bold. There is one byte per K value, represented in the output as 2 hex characters.

If our neighbor has K values as:
EIGRP metric weight K1=1, K2=1, K3=0, K4=0, K5=0
Our output from the debug would resemble the output below.

01:04:28: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
0F4019C0: 0100 5E00000A ..^...
0F4019D0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
0F4019E0: 0158239B 88012D04 E000000A 0205EDC9 .X#...-.`.....mI
0F4019F0: 00000000 00000000 00000000 00000001 ................
0F401A00: 0001000C 01010000 0000000F 00040008 ................
0F401A10: 0C040102 ....

The K values are conveniently displayed in order in the debug output. Remember, when you implement K values under the EIGRP routing process using the metric weights command, the first value is the TOS bit, and then the remaining 5 values are the K values in order 1-5.

One more example is called for, because the K values are not restricted to the values of 0 or 1. What if the remote neighbor had used the following under the EIGRP routing process:
metric weights 0 225 1 1 1 1
Then, on the local router, the debug output would look similar to the following:

01:23:07: IP: s=136.1.45.4 (FastEthernet0/1), d=224.0.0.10, len 60, rcvd 2, proto=88
0F8000E0: 0100 5E00000A ..^...
0F8000F0: 00444444 44440800 45C0003C 00000000 .DDDDD..E@.<....
0F800100: 0158239B 88012D04 E000000A 02050EC9 .X#...-.`......I
0F800110: 00000000 00000000 00000000 00000001 ................
0F800120: 0001000C E1010101 0100000F 00040008 ....`...........
0F800130: 0C040102 ....

225 in binary is 1110 0001. If we convert 1 nibble at a time to Hexadecimal, it would become E1 as shown in the debug output. We could then set our K values to match the neighbor and form a working adjacency.

Of course, in an environment where we manage both routers, we could just look at the output of "show ip protocols", or "show run | section router", and solve it immediately, but where is the challenge in that!

Good luck with your studies.

If you know of other solutions, please add it as a post, and share it with your peers, (assuming your K-values match your peers ;-).

Subscribe to INE Blog Updates