CCIE Blog » Bryan Bartik

Router IP Traffic Export (RITE)

Bryan Bartik — Thu, 01 Jul 2010 13:07:25 +0000

IP Traffic Export is a lot like SPAN for switches, except it is for routers. A copy of traffic received on configured interfaces is exported out another interface while the original flow is not impacted.

This diagram sums what happens and below we take a look at the configuration.

R2’s configuration is pretty simple:

ip traffic-export profile EXPORT
 interface FastEthernet3/0
 bidirectional
 incoming access-list 100
 outgoing access-list 101
 mac-address 001d.6094.d09d
 incoming sample one-in-every 5
 outgoing sample one-in-every 5
!
interface FastEthernet1/0
 ip traffic-export apply EXPORT
!
access-list 100 permit tcp any any eq telnet
access-list 101 permit tcp any eq telnet any

The above configuration shows most of the options you can configures. R2 exports traffic passing through interface FastEthernet1/0 in both directions as long as it matches ACL 100 on ingress or ACL 101 on egress. In addition, only 1 out of every 5 packets is actually exported. When the packets are exported, the destination MAC address is modified to that of the analyzer. The MAC address and interface are the only required parameters in the profile.

In this example our analyzer is a PC with Wireshark running. Below is a screenshot of the capture file. You can see that since we only sample 20% of the packets, Wireshark interprets the stream as having lost segments. Also notice the destination MAC address has been modified according to the configuration.

This feature is currently listed on the v4 Routing and Switching blueprint. Not too tough, so get familiar with commands and continue studying!

–
Bryan Bartik
CCIE #23707 (R&S, SP)

Print Friendly

EIGRP: ip default-network command

Bryan Bartik — Mon, 29 Mar 2010 13:05:16 +0000

This is usually one of the more confusing routing protocol commands supported by Cisco. Every couple of months, there is a post about it on GroupStudy or I get a question about it. Hopefully these two scenarios answer most of your questions and show you just exactly how it works!

This is our topology:

Scenario #1: R3 advertises a loopback 3.3.3.3 with a /8 mask

R2 learns 3.0.0.0/8 via EIGRP:

R2#sho ip route | be Gat
Gateway of last resort is not set
C    192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/8 is subnetted, 1 subnets
D       3.0.0.0 [90/2297856] via 192.168.23.3, 00:07:40, Serial1/1
C    192.168.23.0/24 is directly connected, Serial1/1

R2 uses the ip default-network 3.0.0.0 command to mark this as a default route. This now shows up as a “Gateway of last resort” on R2 and R1:

R2(config)#ip default-network 3.0.0.0
R2(config)#^Z
R2#sho ip route | be Gat
Gateway of last resort is 192.168.23.3 to network 3.0.0.0
C    192.168.12.0/24 is directly connected, Serial1/0
*   3.0.0.0/8 is subnetted, 1 subnets
D*      3.0.0.0 [90/2297856] via 192.168.23.3, 00:08:31, Serial1/1
C    192.168.23.0/24 is directly connected, Serial1/1

R1:

R1#sho ip route | be Gat
Gateway of last resort is 192.168.12.2 to network 3.0.0.0
C    192.168.12.0/24 is directly connected, Serial1/0
D*   3.0.0.0/8 [90/2809856] via 192.168.12.2, 00:00:19, Serial1/0
D    192.168.23.0/24 [90/2681856] via 192.168.12.2, 00:12:07, Serial1/0

When a classful network is used as the default, nothing special needs to happen to advertise the network as a candidate default. Let’s see what happens when the network specified is not classful.

Scenario #2: R3 advertises a loopback 3.3.3.3 with a /32 mask.

R2 is learning 3.3.3.3 as a host route. We try to mark it as a candidate default.

R2#sho ip route | be Gat
Gateway of last resort is not set
C    192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2297856] via 192.168.23.3, 00:00:03, Serial1/1
C    192.168.23.0/24 is directly connected, Serial1/1
R2(config)#ip default-network 3.3.3.3

A static route for 3.0.0.0 has been automatically entered into the routing table towards 3.3.3.3!

R2#sho ip route | be Gat
Gateway of last resort is not set
C    192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       3.3.3.3/32 [90/2297856] via 192.168.23.3, 00:03:06, Serial1/1
S       3.0.0.0/8 [1/0] via 3.3.3.3
C    192.168.23.0/24 is directly connected, Serial1/1

Let’s redistribute this into EIGRP.

R2:

R2(config)#router eigrp 10
R2(config-router)#red static

R1:

R1#sho ip route | be Gat
Gateway of last resort is not set
C    192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       3.3.3.3/32 [90/2809856] via 192.168.12.2, 00:04:02, Serial1/0
D EX    3.0.0.0/8 [170/2681856] via 192.168.12.2, 00:02:13, Serial1/0
D    192.168.23.0/24 [90/2681856] via 192.168.12.2, 00:17:10, Serial1/0

Notice that none of the routes are marked as candidate default yet. Now we can use ip default-network 3.0.0.0 on R2:

R2(config)#ip default-network 3.0.0.0
R2#sho ip route | be Gat
Gateway of last resort is 3.3.3.3 to network 3.0.0.0
C    192.168.12.0/24 is directly connected, Serial1/0
*   3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       3.3.3.3/32 [90/2297856] via 192.168.23.3, 00:05:07, Serial1/1
S*      3.0.0.0/8 [1/0] via 3.3.3.3
C    192.168.23.0/24 is directly connected, Serial1/1

R1:

R1#sho ip route | be Gat
Gateway of last resort is 192.168.12.2 to network 3.0.0.0
C    192.168.12.0/24 is directly connected, Serial1/0
3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       3.3.3.3/32 [90/2809856] via 192.168.12.2, 00:05:18, Serial1/0
D*EX    3.0.0.0/8 [170/2681856] via 192.168.12.2, 00:01:01, Serial1/0
D    192.168.23.0/24 [90/2681856] via 192.168.12.2, 00:18:27, Serial1/0

The ip default-network 3.0.0.0 had no impact on the gateway of last resort initially. We first specified 3.3.3.3 as the gateway of last resort. This command entered 3.0.0.0/8 as a static route into the route table, which was then redistributed into EIGRP on R2. We then were able to mark 3.0.0.0 as the default with ip default-network.

Summary:

The ip default-network command will only mark a classful route as a default route. If you need to mark a subnet route (3.3.3.3/32 for example) as a default, the command generates a static route for the classful network. You can then redistribute that static route into EIGRP and mark that as a default with ip default-network command.

Regards,

Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

Introduction to OSPF Sham-Link

Bryan Bartik — Wed, 20 Jan 2010 16:51:02 +0000

When OSPF sites have a backdoor connection, they will by default prefer that link over the MPLS VPN link. Because of the redistribution that occurs, the VPN routes will be seen as inter-area (if OSPF process numbers match on PEs), E1 or E2 routes. As you probably know by now, inter-area and external routes are less preferred than intra-area routes in OSPF. No amount of administrative distance-altering or interface cost- changing can affect this decision making. Here we look briefly at a feature designed to allow VPN routes to look like intra-area routes, giving us the ability to prefer them over the VPN connection by adjusting interface costs.

Our topology is as follows:

R1 = 10.1.1.1

R2 = 10.1.1.2

After we setup the VPN, R1 has the following entry to R2’s loopback, via the FastEthernet link between them:

R1#sho ip route 10.1.1.2
Routing entry for 10.1.1.2/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 192.168.12.2 on FastEthernet0/0, 00:01:24 ago
Routing Descriptor Blocks:
* 192.168.12.2, from 10.1.1.2, 00:01:24 ago, via FastEthernet0/0
Route metric is 2, traffic share count is 1

In order for R1 to prefer the link to R3, we need to create a sham-link between R3 and R4. Note that OSPF is already set up between the PE and CE routers and redistribution in the VRFs has been configured.

The first step is to create a loopback in the VRF on R3 and R4:

R3(config)#int lo 100
R3(config-if)#ip vrf forwarding VPN1
R3(config-if)#ip address 100.1.1.3 255.255.255.255
R4(config)#int lo 100
R4(config-if)#ip vrf forwarding VPN1
R4(config-if)#ip address 100.1.1.4 255.255.255.255

The second step is to add the loopback into BGP (not OSPF) via the network command under the vrf address-family for that VPN:

R3(config)#router bgp 100
R3(config-router)#address-family ipv4 vrf VPN1
R3(config-router-af)#network 100.1.1.3 mask 255.255.255.255
R4(config)#router bgp 100
R4(config-router)#address-family ipv4 vrf VPN1
R4(config-router-af)#network 100.1.1.4 mask 255.255.255.255

The last step is to create the sham-link under the OSPF process:

R3(config)#router ospf 100 vrf VPN1
R3(config-router)#area 0 sham-link ?
A.B.C.D  IP addr associated with sham-link source
R3(config-router)#area 0 sham-link 100.1.1.3 100.1.1.4

R4(config)#router ospf 100 vrf VPN1
R4(config-router)#area 0 sham-link 100.1.1.4 100.1.1.3

You should see a log message similar to the following:

%OSPF-5-ADJCHG: Process 100, Nbr 192.168.13.3 on OSPF_SL0 from LOADING to FULL, Loading Done

The final step is to adjust the cost on the links to make the PE-CE link preferred. Since we are now dealing with intra-area routes, cost can be used to influence path selection.

R1(config)#int f0/0
R1(config-if)#ip osp cost 10000

R2(config)#int f0/0
R2(config-if)#ip osp cost 10000

R1 should now prefer R3 to reach R2:

R1#trace 10.1.1.2

Type escape sequence to abort.
Tracing the route to 10.1.1.2
1 192.168.13.3 20 msec 52 msec 16 msec
2 192.168.24.4 [MPLS: Label 18 Exp 0] 20 msec 24 msec 16 msec
3 192.168.24.2 44 msec *  8 msec
R1#

There are lots of more details we can look at but for now I hope that gives you a brief introduction to OSPF sham-link. Good luck!

Bryan Bartik

CCIE #23707 (R&S, SP), CCNP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

Print Friendly

RP Announce Filter

Bryan Bartik — Mon, 28 Dec 2009 14:15:48 +0000

In this post we look at a sometimes misunderstood command, ip pim rp-announce-filter, and figure out how it is used to filter unwanted devices from becoming RPs. The topology for this example is very small, just two routers.

R1—R2

Requirements:

R1 = 1.1.1.1, R2 = 2.2.2.2

R1 is the Mapping Agent.

R1 should be the RP for 239.0.0.1.

No other router device should be allowed to be RP for any other group.

R1 is configured as the MA and RP while R2 is also configured as an RP, so we can test our filtering commands. After this initial configuration we have the following RP information:

R1#sho ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback1)
Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:01:49, expires: 00:02:08
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), via Auto-RP
Uptime: 00:01:46, expires: 00:02:11

R2 has been elected as RP based on higher IP address. Let’s configure our initial filtering policy. An important thing to remember here is that we also have to put an ACL on the ip pim send-rp-announce command. If you announce yourself as RP for a block, the mapping agent cannot split that block up for you. For example, if you announce yourself as RP for 224.0.0.0/4, the mapping agent cannot filter you down to 239.0.0.1 by itself. So R1 must announce itself as RP for 239.0.0.1 in order for the MA to strictly allow only R1 to be RP for only that group. Here is the configuration:

R1(config)#access-list 1 permit 1.1.1.1 0.0.0.0
R1(config)#access-list 2 permit 239.0.0.1 0.0.0.0
R1(config)#ip pim send-rp-announce loopback 1 scope 10 group-list 2
R1(config)#ip pim rp-announce-filter rp-list 1 group-list 2

Wait a few minutes or clear the RP information with the clear ip pim rp-mapping and you should see the following:

R1#sho ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback1)
Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:00:44, expires: 00:02:13
Group(s) 239.0.0.1/32
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:01:04, expires: 00:02:56
R1#

R1 is correctly elected as RP for 239.0.0.1. But notice that R2 is still being learned and elected as an RP for the remaining groups. The ip pim rp-announce-filter command does not filter any RPs that are denied by the RP-list ACL. Since ACL 1 only permits 1.1.1.1 (and implicitly denies the rest), no other RPs are actually filtered. To do this we create a couple more ACLs and apply them to a second ip pim rp-announce-filter command.

R1(config)#access-list 3 deny 1.1.1.1 0.0.0.0
R1(config)#access-list 3 permi any
R1(config)#access-list 4 deny 224.0.0.0 15.255.255.255
R1(config)#ip pim rp-announce-filter rp-list 3 group-list 4

Now we have a working filter that says any router permitted by ACL 3 will be denied from being an RP for any group (224.0.0./4 specified in ACL 4). Remember that we have to deny 1.1.1.1 in ACL 3, otherwise it would be blocked, even though we permit it in the first filter.

Wait a few minutes and verify:

R1#sho ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback1)
Group(s) 239.0.0.1/32
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:03:09, expires: 00:02:49

Hope that explains it. Leave any comments or questions below.

Good luck!

Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

BGP Route Reflection – Troubleshooting

Bryan Bartik — Mon, 21 Dec 2009 13:29:03 +0000

Often when you are a few hours into a lab, some things become a little hazy. You are flying by and everything is working as expected, then you run into a snag. You know the answer will be easy, once you find it. Forgetting to configure route reflection can be one of those things. In this post, we look at the show ip bgp neighbor command to figure how the router tells us that there is no reflection going on. This is of course assuming you couldn’t figure it out with a show run (which happens a lot!).

R1—-R2—-R3

The three routers above are in AS 100. R2 is peered with R1 and R3. R1 is advertising the prefix 192.168.100.1/32 to R2. R2 receives and installs this in the route table, but R3 does not.

Let’s have a look:

R2#sho ip bgp | be Netw
Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.100.1/32 1.1.1.1                  0    100      0 i
R3#sho ip bgp
R3#

On R2, let’s look closer at the BGP entry:

R2#sho ip bgp 192.168.100.1
BGP routing table entry for 192.168.100.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
1.1.1.1 (metric 65) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best

Notice the entry says “Not advertised to any peer” but does not give us a clue why. Let’s look at another command. This is going to give us a lot of output, so I will cut out the part that’s relevant.

R2#sho ip bgp neighbors 3.3.3.3
For address family: IPv4 Unicast
BGP table version 2, neighbor version 2/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent       Rcvd
Prefix activity:               ----       ----
Prefixes Current:               0          0
Prefixes Total:                 0          0
Implicit Withdraw:              0          0
Explicit Withdraw:              0          0
Used as bestpath:             n/a          0
Used as multipath:            n/a          0
Outbound    Inbound
Local Policy Denied Prefixes:    --------    -------
Bestpath from iBGP peer:              1        n/a
Total:                                1          0
Number of NLRIs in the update sent: max 0, min 0

In the last few lines of output we see a section called “Local Policy Denied Prefixes.” A count and a reason of why prefixes have been denied are summarized in this section. We can see that one route has been denied outbound to this neighbor because “Bestpath from iBGP peer.” What does this mean? It means that the best path was learned through an IBGP peer and thus is not advertised to this (the one specified in the command outbound) IBGP peer. It would be nice for the output to say “Route reflection is not configured” but that’s wouldn’t be quite right since you could also use confederations!

This section of the command may also give other clues such as a route-map or prefix-list that could be blocking an advertisement. Plus, it displays inbound and outbound. One of my favorite commands just for digging around!

Good luck!

Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

MPLS Label Filtering

Bryan Bartik — Mon, 07 Dec 2009 17:21:27 +0000

In this post we look at a way to filter labels in an MPLS environment. In many MPLS environments, labels are only needed for PE loopbacks and having LFIB entries for connected network is unnecessary. For this post we have the following topology with R1 and R3 as PE routers.

R1—R2—R3

After MPLS is enabled, R1 has the following LFIB:

R1#sho mpl forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     10.1.1.2/32       0          Se1/0      point2point
17     Pop tag     192.168.23.0/24   0          Se1/0      point2point
18     17          10.1.1.3/32       0          Se1/0      point2point

R1 only needs labels for 10.1.1.3 (R3’s loopback) and not R2 nor the link between R2 and R3. R1 can filter these labels as follows:

R1(config)#access-list 1 per 10.1.1.3
R1(config)#mpl ldp neighbor 10.1.1.2 labels accept 1
R1#sho mpl forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Untagged    10.1.1.2/32       0          Se1/0      point2point
17     Untagged    192.168.23.0/24   0          Se1/0      point2point
18     17          10.1.1.3/32       0          Se1/0      point2point
R1#

Notice the entries for R2 and 192.168.23.0 are now “Untagged” instead of “Pop Tag”. R1 has only allowed a label for 10.1.1.3 to be installed in the LIB, and is therefore the only label available to be installed in the LFIB.

R1#sho mpl ldp bindings neighbor 10.1.1.2
tib entry: 10.1.1.3/32, rev 12
remote binding: tsr: 10.1.1.2:0, tag: 17

Regards,

Bryan Bartik

CCIE #23707 (R&S, SP), CCNP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

Print Friendly

MPLS IP TTL Propagation

Bryan Bartik — Wed, 25 Nov 2009 05:27:29 +0000

In this post we will look at what happens to the TTL value of a packet when it enters the MPLS VPN. We will also see how we can change that behavior to hide the provider network from customers.

R4(CE)—R5(PE)—R9(P)—R8(P)—R6(PE)

R4 is a CE router communicating with a VRF on R6.

R6 is a PE but has a loopback in the VRF.

Scenario #1: Default

By default, TTL is propagated and R4 will see each device along the path to R6.

R4’s trace:

1 100.5.4.5 [AS 100] 56 msec
2 100.9.5.9 [MPLS: Labels 901/605 Exp 0] 76 msec
3 100.9.8.8 [MPLS: Labels 800/605 Exp 0] 52 msec
4 192.168.6.6 [AS 100] 44 msec

Summary:

R4 sends packet with TTL of 1.

R5 receives this, decrements the TTL to 0 and sends TTL exceeded back.

R4 sends packet with TTL of 2.

R5 decrements this to 1 and copies the value of 1 to both MPLS label headers.

R9 sends a TTL exceeded message back with MPLS extension field that describes the labels that were on the packet at the time it was received.

R8 does the same as R9.

Finally R6 responds with port unreachable messages.

Scenario #2: TTL Propagation disabled on ingress LSR R5

R5(config)#no mpls ip propagate-ttl

R4’s trace:

1 100.5.4.5 [AS 100] 48 msec
2 192.168.6.6 [AS 100] 72 msec

Summary:

R4 sends packet with TTL of 1.

R5 receives this, decrements the TTL to 0 and sends TTL exceeded back.

R4 sends packet with TTL of 2.

R5 decrements this to 1 and imposes 2 labels but puts the TTL at 255.

The packet makes it through the entire MPLS network before expiring this time at R6.

Scenario #3: TTL Propagation allowed for traffic generated from LSR

In Scenario 2 we prevented the TTL from the IP header from being copied to the MPLS TTL field. This hides the provider network from the customer but also from us on the PE devices!

R5#trace vrf VPNA 192.168.6.6
Type escape sequence to abort.
Tracing the route to 192.168.6.6
1 192.168.6.6 88 msec *  64 msec
R5#

We have another option that allows the ingress LSR to copy the IP TTL field if it is the router generating the packet.

R5(config)#no mpls ip propagate-ttl  ?
forwarded  Propagate IP TTL for forwarded traffic
local      Propagate IP TTL for locally originated traffic

R5(config)#mpl ip propagate-ttl
R5(config)#no mpls ip propagate-ttl forwarded

Notice we have to enable it globally, then disable the forwarded option. Now let’s look at put traces.

R4 doesn’t see the P routers:

R4#trace 192.168.6.6
Type escape sequence to abort.
Tracing the route to 192.168.6.6
1 100.5.4.5 [AS 100] 16 msec 84 msec 36 msec
2 192.168.6.6 [AS 100] 40 msec *  56 msec
R4#

R5 does:

R5#trace vrf VPNA 192.168.6.6
Type escape sequence to abort.
Tracing the route to 192.168.6.6
1 100.9.5.9 [MPLS: Labels 901/605 Exp 0] 80 msec 76 msec 28 msec
2 100.9.8.8 [MPLS: Labels 801/605 Exp 0] 40 msec 28 msec 28 msec
3 192.168.6.6 48 msec
R5#

Hope this gives you a little more insight into how we can hide the provider network from VPN customers.

Good luck,

Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

MPLS and BGP-Free Core

Bryan Bartik — Thu, 19 Nov 2009 05:02:22 +0000

In this post, we look at how MPLS and LDP are used to build an LSP between two BGP speaking routers. The routers will share IBGP routes with each other, however they will not share BGP routes with an intermediate router nor will they redistribute BGP routes into the IGP. Labels are used to forward packets the proper next-hop. For those familiar with MPLS VPN already, this works very similarly however we have no VRFs.

Our topology is simple. All routers run OSPF with R1 and R3 learning each other’s loopback interfaces via OSPF and forming a BGP session between them.

R1—R2—-R3

R1#sho ip rou osp
10.0.0.0/32 is subnetted, 3 subnets
O       10.1.1.2 [110/65] via 192.168.12.2, 00:00:01, Serial1/0
O       10.1.1.3 [110/129] via 192.168.12.2, 00:00:01, Serial1/0
O    192.168.23.0/24 [110/128] via 192.168.12.2, 00:00:01, Serial1/0
R1#sho ip bgp summary | be Neigh
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.3        4   100       2       2        0    0    0 00:00:09        0
R1#

R1 and R3 will each add a new loopback and advertise it into BGP:

R1(config)#int lo 100
R1(config-if)#ip address 100.1.1.1 255.255.255.255
R1(config-if)#router bgp 100
R1(config-router)#net 100.1.1.1 mask 255.255.255.255
R3(config)#int lo 100
R3(config-if)#ip address 100.1.1.3 255.255.255.255
R3(config-if)#router bgp 100
R3(config-router)#network 100.1.1.3 mask 255.255.255.255

R1 and R3 learn these new networks via IBGP however R2 knows nothing about them and thus communication between the loopbacks is not possible.

R3#sho ip route bgp
100.0.0.0/32 is subnetted, 2 subnets
B       100.1.1.1 [200/0] via 10.1.1.1, 00:01:20
R2#sho ip route 100.1.1.1
% Network not in table
R2#sho ip route 100.1.1.3
% Network not in table
R1#ping 100.1.1.3 sou lo 100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.3, timeout is 2 seconds:
Packet sent with a source address of 100.1.1.1
.....
Success rate is 0 percent (0/5)
R1#

Now let’s enable LDP on the links between R1, R2 and R3.

R1(config)#mpls ldp rou lo 0
R1(config)#int s1/0
R1(config-if)#mpls ip
R2(config)#mpl ldp rou lo 0
R2(config)#int s1/1
R2(config-if)#mpls ip
R2(config-if)#int s1/0
R2(config-if)#mpls ip
R3(config)#mpls ldp rou lo 0
R3(config)#int s1/1
R3(config-if)#mpls ip

Once the LDP peers come up you should have an LSP built between R1 and R3’s loopback 0 interfaces.

R1#sho mpl forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     16          10.1.1.3/32       0          Se1/0      point2point
17     Pop tag     192.168.23.0/24   0          Se1/0      point2point
18     Pop tag     10.1.1.2/32       0          Se1/0      point2point
R1#sho ip route bgp
100.0.0.0/32 is subnetted, 2 subnets
B       100.1.1.3 [200/0] via 10.1.1.3, 00:06:13
R1#

Now when R1 sends packets to 100.1.1.3 is uses label 16 since that is the label for the next-hop. Since R2 is participating in OSPF and LDP, it also has learned a label for 10.1.1.3 so it can forward packets correctly.

R2#sho mpl forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     10.1.1.3/32       189        Se1/0      point2point
17     Pop tag     10.1.1.1/32       321        Se1/1      point2point
R1#ping 100.1.1.3 source lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.3, timeout is 2 seconds
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/43/68 ms
R1#

Thanks!

Bryan Bartik
CCIE #23707 (R&S & SP), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

IPv6 – Why Does the Router Need to Know if an Address is Anycast?

Bryan Bartik — Wed, 21 Oct 2009 14:46:55 +0000

Recently a good question was posted on Groupstudy asking why a router needs to know that an IPv6 address is an anycast address. I often wondered this myself and it turns out, the router does not perform Duplicate Address Detection as it does for normal unicast addresses. A small lab scenario will suffice to give use the results!

First turn on debugging:

R2#debug ipv6 nd 
ICMP Neighbor Discovery events debugging is on
R2#

Next assign one unicast address and one anycast address and see the difference:

R2(config)#int s1/1 
R2(config-if)# ipv6 address 2004::2/64 
*Mar  1 07:24:14.374: ICMPv6-ND: Adding prefix 2004::2/64 to Serial1/1
*Mar  1 07:24:14.378: ICMPv6-ND: Sending NS for 2004::2 on Serial1/1
*Mar  1 07:24:15.382: ICMPv6-ND: DAD: 2004::2 is unique.
*Mar  1 07:24:15.386: ICMPv6-ND: Sending NA for 2004::2 on Serial1/1
*Mar  1 07:24:15.390: ICMPv6-ND: Address 2004::2/64 is up on Serial1/1
 
R2(config-if)# ipv6 address 2005::2/64 anycast
*Mar  1 07:24:23.142: ICMPv6-ND: Adding prefix 2005::2/64 to Serial1/1
*Mar  1 07:24:23.142: ICMPv6-ND: Sending NA for 2005::2 on Serial1/1
*Mar  1 07:24:23.146: ICMPv6-ND: Address 2005::2/64 is up on Serial1/1

When you assign a normal IPv6 unicast address, the router sends a Neighbor Solicitation (NS) message to see if any neighbors may already be using that address. Once the timeout expires, it declares the address as unique and sends a Neighbor Advertisement for this address. When you define an anycast address, it is assumed that other routers may use the address. Whether or not they are on the same link doesn’t really matter, so DAD is not necessary. So, the router skips the NS message and goes right to the NA.

Good luck!

Bryan Bartik
CCIE #23707 (R&S), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly

ISIS – Priority-Driven Prefix RIB Installation

Bryan Bartik — Mon, 19 Oct 2009 12:35:29 +0000

As the name suggests, this feature allows routes with a specific tag to be installed in the RIB faster than other prefixes. By default, the highest priority prefixes are ones with /32 masks. As we will see here, we can tag routes to give them a higher priority than /32 prefixes.

The command we will be using to see this in action is:

R3#debug isis local-updates
IS-IS local updates debugging is on
R3 is in an L1 area with 2 routers, R1 and R2.
R1 is advertising 10.1.1.1/32, 10.1.11.1/32 and redistributing 200.0.0.0/24.
R2 is advertising 10.1.1.2/32 and 10.1.20.0/24.

The other routes you see in the debugs are connected routes between routers.

Let’s clear IS-IS on R3 and see what routes have the highest priority:

*Mar  1 17:35:50.883: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.1
*Mar  1 17:35:50.891: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 10.1.11.1
*Mar  1 17:35:50.895: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.2
*Mar  1 17:35:50.899: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.113.0
*Mar  1 17:35:50.903: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.12.0
*Mar  1 17:35:50.907: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 200.0.0.0
*Mar  1 17:35:50.915: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 10.1.20.0

Notice all the /32 prefixes were processed first. Then rest were processed in no particular order. Suppose we want the 200.0.0.0 route processed first. We could do the following (Wide-metrics must be enabled):

On R1 tag the route during redistribution:

R1(config)#route-map con2isis 10
R1(config-route-map)#set tag 1000
R1(config-route-map)#router isis
R1(config-router)#redistribute connected route-map con2isis level-1

On R3, we configure the router to give priority to tag 1000:

R3(config)#router isis
R3(config-router)#ip route priority high tag 1000

Clear ISIS on R3:

R3#cle isis *
*Mar  1 17:40:27.475: ISIS-Upd: Building L1 LSP
*Mar  1 17:40:27.955: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->1000) change, 200.0.0.0
*Mar  1 17:40:27.959: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.2
*Mar  1 17:40:27.963: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.1
*Mar  1 17:40:27.967: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 10.1.11.1
*Mar  1 17:40:27.971: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.12.0
*Mar  1 17:40:27.971: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 10.1.20.0
*Mar  1 17:40:27.971: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.113.0

The routes with tag 1000 are processed first every time. Let’s tag 10.1.20.0 on R2, it is loopback 20.

R2(config)#int lo 20
R2(config-if)#isis tag 1000
R3#cle isis *
*Mar  1 17:41:45.259: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->1000) change, 10.1.20.0
*Mar  1 17:41:45.263: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->1000) change, 200.0.0.0
*Mar  1 17:41:45.267: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.2
*Mar  1 17:41:45.271: ISIS-Loc: L2 non-summarized metric(4294967295->10)or route-type(->L1) or tag (0->0) change, 10.1.1.1
*Mar  1 17:41:45.275: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 10.1.11.1
*Mar  1 17:41:45.283: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.12.0
*Mar  1 17:41:45.287: ISIS-Loc: L2 non-summarized metric(4294967295->20)or route-type(->L1) or tag (0->0) change, 192.168.113.0

So to summarize:

Enable wide metrics for this to work, otherwise tag is not advertised.
You can set tag in a route-map during redistribution or at the interface level with “isis tag”
Use the “ip route priority high” command on the router which needs to give priority to the prefixes.

Bryan Bartik
CCIE #23707 (R&S), CCNP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly