Multicast over NBMA with auto-rp and a spoke mapping agent

Here is the topology. There is no PVC between R2 and R3. Nice frame cloud, eh?


R1 (hub), R2 and R3 are connected via frame-relay: 172.12.123.0/24.
R4 connects to R3 via another serial connection: 192.168.14.0/24.

OSPF area 0 is everywhere.

R1 will be the RP-candidate.
R3 will be the mapping agent.
R2 will be joining group 232.0.0.2.
R4 will sending pings to 232.0.0.2.

R1 will announce itself as RP candidate and R3 as the MA:

R1(config)#ip pim send-rp-announce lo 0 scope 5

R3(config)#ip pim send-rp-discovery loopback 0 scope 5

Now according to this doc:

Using IP Multicast Over Frame Relay Networks

"All candidate RPs must be connected to the MA"
AND
"All MAs must be connected to all PIM routers"

In order for R2 to successfully receive the rp-to-group mappings from R3, they need to be PIM neighbors. The reason is R1 will not forward an autorp message received on it's frame-relay interface back out that same interface. So R2 will never get it!

We can create a tunnel between the two and enabling sparse-mode on the tunnel:

R2(config)#int tun 0
R2(config-if)#ip address 172.12.23.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel destination 172.12.123.3
R2(config-if)#ip pim sparse-mode

R3(config)#int tun 0
R3(config-if)#ip address 172.12.23.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel destination 172.12.123.2
R3(config-if)#ip pim sparse-mode

Now R2 and R3 are PIM neighbors:

R2#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.12.123.1 Serial1/0 01:44:07/00:01:38 v2 1 / S
172.12.13.3 Tunnel0 00:06:29/00:01:42 v2 1 / S

However theres is still one issue. When R2 receives the auto-rp messages from R3 the rpf check fails because R2 uses its FR interface to perform the rpf check:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Serial1/0
RPF neighbor: ? (172.12.123.1)
RPF route/mask: 3.3.3.3/32
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Thus R2 will never learn the rp-to-group mapping. We can fix this by making a static mroute for R3's loopback pointing towards the tunnel:
R2(config)#ip mroute 3.3.3.3 255.255.255.255 Tunnel0


Now the RPF will pass for auto-rp messages:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Tunnel0
RPF neighbor: ? (172.12.23.3)
RPF route/mask: 3.3.3.3/32
RPF type: static
RPF recursion count: 0
Doing distance-preferred lookups across tables

Let's verify on R4:

R4#ping 232.0.0.2 repeat 5

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

Reply to request 0 from 172.12.123.2, 500 ms
Reply to request 1 from 172.12.123.2, 188 ms
Reply to request 2 from 172.12.123.2, 492 ms
Reply to request 3 from 172.12.123.2, 300 ms
Reply to request 4 from 172.12.123.2, 292 ms

Sweet!

Configuring multipoint subinterface so the interface status reflects status of the PVC

On a physical frame-relay interface, if the opposite end goes down, the local interface will remain up/up. When using multipoint subinterfaces this is not the case. When the remote interface goes down (taking the dlci with it), the local ends puts its interface in a down/down state.

R1, R3 and R5 connect via full mesh frame-relay, subnet 190.1.135.0/24

R1 dlci 103 maps to R3 dlci 301
R1 dlci 105 maps to R5 dlci 501
R3 dlci 305 maps to R5 dlci 503

Configure all routers on the physical interfaces.

Here is the outlook so far from R3:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up
R3#

Now Let's shut the physical interfaces On R5 and R1:

R5(config)#int s0/0
R5(config-if)#shut

R1(config)#int s0/0
R1(config-if)#shut

R3 still has its interface up/up:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up

If we want R3's interface to go down when R5 and R1 are no longer available we need to use multipoint subinterface. Let's create one on R3 and move the config over:

R3(config)#interface Serial1/0
R3(config-if)# no ip address 190.1.135.1 255.255.255.0
R3(config-if)# no frame-relay map ip 190.1.135.1 301
R3(config-if)# no frame-relay map ip 190.1.135.5 305
R3(config-if)#int s1/0.3 multipoint
R3(config-subif)# ip address 190.1.135.1 255.255.255.0
R3(config-subif)# frame-relay map ip 190.1.135.1 301 broadcast
R3(config-subif)# frame-relay map ip 190.1.135.5 305 broadcast
R3(config-subif)# no frame-relay inverse-arp

Bring up R5 and R1 again and now we have:

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

Shut down R5 and R3 is stil up but look at the debug frame-relay lmi. The status of PVC 305 is 0x0 which is inactive

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

*Mar 1 08:27:43.170: Serial1/0(in): Status, myseq 115, pak size 45
*Mar 1 08:27:43.170: RT IE 1, length 1, type 0
*Mar 1 08:27:43.170: KA IE 3, length 2, yourseq 115, myseq 115
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 301, status 0x2 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 302, status 0x0 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 304, status 0x2 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 305, status 0x0 , bw 0

Now let's shut down R1 and take a look at R3 again, notice pvc 301 is now status 0x0. and the interface is down/down on R3

*Mar 1 08:30:03.170: Serial1/0(in): Status, myseq 129, pak size 45
*Mar 1 08:30:03.170: RT IE 1, length 1, type 0
*Mar 1 08:30:03.170: KA IE 3, length 2, yourseq 129, myseq 129
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 301, status 0x0 , bw 0
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 302, status 0x0 , bw 0
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 304, status 0x2 , bw 0
*Mar 1 08:30:03.174: PVC IE 0x7 , length 0x6 , dlci 305, status 0x0 , bw 0

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual down down

Route Redistribution Issues Part I – RIP and OSPF

This is part of task I had on IEWB volume 3 workbook lab 1. I tweaked it a little. I wanted to get better idea of redistribution when there are multiple points of redistribution. It is always the hardest concept for me to get my head around because there so many things going on. I know the tasks may only be a few points, but it affects reachability which can hurt you later if you do not have it.

If you develop a thought process for it and recognize patterns and spot issues beforehand, you will be better off. I don't have any configurations here, just my thought flow. I was doing this practice lab at the same but I just wanted to document the thoughts.


Perform redistribution between RIP and OSPF on R4 and R5 and ensure reachability to the loopback interfaces on R1 and R9 from anywhere when R4 or R5’s frame link are down. If both are down then reachability to R9 and R1 cannot be achieved from R2.

Thought Process:

First thing I would do is identify which networks need to be learned via each protocol on each router, along with back up routes:

Router	Destination	Primary Route	Backup Route
R1	R9, LAN59	RIP via R4	n/a
R4	R9, LAN59 R1	RIP via R5 RIP via R1	OSPF via R5 n/a
R5	R1, LAN14 R9	RIP via R4 RIP via R9	OSPF via R4 n/a
R9	R1, LAN14	RIP via R5	n/a
R2	All	OSPF via R4 or R5	n/a

Next thing is to break down the redistribution into steps. These steps can be in various orders which may affect traffic flow, but I like to start with the edge networks in and resolve issues as we progress. We have 4 steps here:

Step 1: Redistribute RIP into OSPF on R5
R2 now has access to R9 loopback and LAN59 via R5
R5 has no changes to it’s routes
R4 now learns the route to R9 and LAN59 via OSPF through R5
R1 no longer has a route to R9 or LAN59 because R4 learns these via OSPF, not RIP anymore

Step 2: Redistribute RIP into OSPF on R4
R2 now has access to R1 loopback and LAN14 via R4.
R4 is the same as in step 1.
R5 now learns the route to R1 Loopback and LAN14 via OSPF through R4
R9 cannot reach R1 anymore because R5 is learning R1 and LAN14 through OSPF, not RIP

Issues remaining after steps 1 and 2:
R1 or R9 cannot respond to pings from R2 because they do not have a route for the OSPF network.
R1 and R9 cannot reach each other’s loopbacks or connected LANs.

Step 3: Redistribute OSPF into RIP on R4
Here is we encounter a loop. The reason is that once R4 does this it will now advertise RIP routes back to R1 and R5 that may have already been in RIP to begin with. So the problems will be with any existing RIP routes on these routers. R5 currently has a RIP route for R9 loopback with a metric of 1. R4 is going to redistribute this route back to R5 also with a mteric of 1 (the metric is up to use, but I use 1 for example). R5 now will load share between two routes to R9. One router will be a loop (the one through R4). R5 has no way of knowing that this route is the same route it redistributed into OSPF. We can resolve this by setting a higher metric on the routes that R4 redistributes into RIP. Setting the metric to 2 in this example resolves the issue.

R2 now has reachability to R1 and LAN14, but still no reachability to R9 because R9 has no route back. R9 also has no route to R1.

Step 4: Redistribute OSPF into RIP on R5
In the final step of redistribution R5, we may cause another loop by advertising R1’s loopback back to R4 over the serial link with a metric 1. However, we set the metric to 2 to rpevent this.

Shutting down serial link between R4 and R5:
Because this link is not used for any transit networks, this link does not affect reachability to R1 or R9 whether up or down.

Shutting down only R5 frame-relay interface:
R5 loses its OSPF networks and learns all routes via RIP through R4. R4 uses the RIP link to reach R9 and LAN59.

Shutting down only R4 frame-relay interface:
R4 loses it OSPF networks and learns all routes via RIP through R5. LAN14 and R1 are still learned directly from R1.

Allowing telnet to a non-standard port

I didn't have time for any of the security tasks in Mock Lab 1. There were 3 for a total of 9 points. Again, the lab sessions run 7:45 and I had to load initial configs and eat dinner! Had I been able to use the full 8 hours, I am sure I would have gotten 1 or 2 of these tasks.

Here is the gist of the first security task, 9.1:

R9 should accept telnet on port 3005.
It should not allow telnet on port 23.
Configure a local user cisco with password of cisco and privilege level 15.
Telnet should require a login, but console access should not

I am going to use R5 as an example since I already have it up in Dynamips. First, to allow telnet on port 3005 use the rotary command:

R5(config)#username cisco privilege 15 password cisco
R5(config-line)#line vty 5
R5(config-line)#rotary 5
R5(config-line)#login local

Next we create an ACL to block telnet to port 23:

R5(config)#access-list 101 deny tcp any any eq telnet
R5(config)#access-list 101 permit ip any any
R5(config)#line vty 0 ?
<1-935> Last Line number


R5(config)#line vty 0 935
R5(config-line)#access-class 101 in

Let's try from R4:

R4#telnet 141.141.45.5
Trying 141.141.45.5 ...
% Connection refused by remote host

R4#telnet 141.141.45.5 3005
Trying 141.141.45.5, 3005 ... Open


User Access Verification

Username: cisco
Password:
R5#

Now we have already satisfied the last requirement right? "Telnet should require a login, but console access should not." But for some reason the proctor guide goes a step further and creates an aaa method for VTY while console uses the default. Here's what they have:

R5(config)#aaa new-model
R5(config)#aaa authentication login VTY local
R5(config)#aaa authentication login default none
R5(config)#line vty 5
R5(config-line)#login authentication VTY

The first command tells the router to enable the aaa commands. The second command defines a login list called VTY. Note that this is not used anywhere until it is applied in the last command. The third command configures that default login method to be "none" or no authentication. This method is applied to the console by default.

PPP over Frame-relay with CHAP

Another task I had trouble with in Mock Lab 1 was 2.2 which is a PPP over FR task.

Here it is:

"For the connection between R4 and R5, use a PPP over frame configuration with RFC 1973 encapsulation. The connection should use CHAP authentication. For authentication both devices should use a username of T3ST123 and a password of PPPoverFr@m3. Both sides should challenge an respond."

I got PPP over FR to work fine, but when I enabled authentication it wasn't working so I skipped the task, instead just going for reachability.

Here I try it again. First, just with PPP over FR and no auth:

R4:

R4(config)#int virtual-template 1
R4(config-if)#ip address 141.141.45.4 255.255.255.0
R4(config-if)#exit
R4(config)#int s1/0
R4(config-if)#encapsulation frame-relay
R4(config-if)#frame-relay interface-dlci 405 ppp virtual-Template 1
R4(config-if)#frame-relay map ip 141.141.45.5 405 broadcast
R4(config-if)#no shut

R5:

R5(config)#int virtual-template 1
R5(config-if)#ip address 141.141.45.5 255.255.255.0
R5(config-if)#exit
R5(config)#int s1/0
R5(config-if)#encapsulation frame-relay
R5(config-if)#int s1/0.2 multipoint
R5(config-subif)#frame-relay interface-dlci 504 ppp virtual-Template 1
R5(config-subif)#frame-relay map ip 141.141.45.4 504 broadcast
R5(config-subif)#int s1/0
R5(config-if)#no shut

Verify:

R4#ping 141.141.45.5

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

Easy enough, right? Let's add CHAP:

R4(config)#username T3ST123 password PPPoverFr@m3
R4(config)#int virtual-template 1
R4(config-if)#ppp authentication chap
R4(config-if)#ppp chap hostname T3ST123
R4(config-if)#ppp chap password PPPoverFr@m3

R5(config)#username T3ST123 password PPPoverFr@m3
R5(config)#int virtual-template 1
R5(config-if)#ppp authentication chap
R5(config-if)#ppp chap hostname T3ST123
R5(config-if)#ppp chap password PPPoverFr@m3

Notice the error we get when we try and bring up the link. R4 is ignoring the username because that's what it is using:

R4#debug ppp authentication
PPP authentication debugging is on
R4#ping 141.141.45.5

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

*Mar 1 00:14:42.211: Vi1 CHAP: I CHALLENGE id 18 len 28 from "T3ST123"
*Mar 1 00:14:42.211: Vi1 CHAP: Ignoring Challenge with local name
*Mar 1 00:14:42.247: Vi1 AUTH: Timeout 2
*Mar 1 00:14:42.247: Vi1 CHAP: O CHALLENGE id 27 len 28 from "T3ST123"
*Mar 1 00:14:52.247: Vi1 CHAP: I CHALLENGE id 19 len 28 from "T3ST123"
*Mar 1 00:14:52.247: Vi1 CHAP: Ignoring Challenge with local name
*Mar 1 00:14:52.263: Vi1 AUTH: Timeout 3
*Mar 1 00:14:52.263: Vi1 CHAP: O CHALLENGE id 28 len 28 from "T3ST123"
*Mar 1 00:15:02.271: Vi1 CHAP: I CHALLENGE id 20 len 28 from "T3ST123"
*Mar 1 00:15:02.271: Vi1 CHAP: Ignoring Challenge with local name

What's the answer? Well it turns out the command is not documented very well. I actually gave up and looked in the procotor guide:

R4(config)#int virtual-template 1
R4(config-if)#no ppp chap ignoreus

R5(config)#int virtual-template 1
R5(config-if)#no ppp chap ignoreus

The option doesn't even show up in context-sensitive help:

R4(config-if)#ppp chap ?
hostname Set alternate CHAP hostname
password Set default CHAP password
refuse Refuse to authenticate using CHAP
wait Wait for caller to authenticate first

In fact, I didn't find any mention of it on the DocCD and only 3 results came up in Google! One of them was this link:

Understanding and Configuring PPP CHAP Authentication

Well I guess that's how it goes in the life of a CCIE candidate

PPP - Address negotiation, authentication, and some lcp/ipcp options

Today and the next couple days I am reviewing everything I got wrong on IPexpert Volume 3 Mock Lab 1. I am setting up small networks to handle each task separately in order to completely understand the solution.

I had a PPP task which I skipped because I did not know how to do it. It was 3 points and to get reachability I just setup standard PPP.

Here is the task:

"Configure the serial link connecting R2 and R5 for PPP encapsulation, using plaintext authentication. R2 should recieve its address from R5. Configure for a maximum of 3 bad authentication retries. Configure link control and IP control to predict peer responses."

So I have a small network in Dynamips:

[R2]s1/1---s1/1[R5]

Where to begin? Let's do ip addressing first:

R5(config)#int s1/1
R5(config-if)#encapsulation ppp
R5(config-if)#ip address 141.41.205.5 255.255.255.0
R5(config-if)#peer default ip address 141.41.205.2

R2(config)#int s1/1
R2(config-if)#encapsulation ppp
R2(config-if)#ip address negotiated

After enabling interfaces, here is the debug ppp negotiation output:

*Mar 1 01:41:16.819: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)
*Mar 1 01:41:16.823: Se1/1 IPCP: O CONFREQ [ACKsent] id 2 len 10
*Mar 1 01:41:16.823: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)
*Mar 1 01:41:16.827: Se1/1 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar 1 01:41:16.831: Se1/1 CDPCP: State is Open
*Mar 1 01:41:16.839: Se1/1 IPCP: I CONFACK [ACKsent] id 2 len 10
*Mar 1 01:41:16.839: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)

R2#show ip int brief | in 1/1
Serial1/1 141.41.205.2 YES IPCP up up

Simple enough but these commands are new to me. They appear in the dial technologies reference on the DocCD so that's a good place to look for PPP related commands. Let's configure authentication.

Do this on R2 as well. I started on R2 which is why you see the interface come back up after it dropped.

R5(config)#username cisco password cisco
R5(config)#int s1/1
R5(config-if)#ppp authentication pap
R5(config-if)#ppp max-bad-auth 3
R5(config-if)#ppp pap sent-username cisco password cisco
PPP: Warning: You have chosen a username/password combination that
is valid for CHAP. This is a potential security hole.
R5(config-if)#
*Mar 1 01:47:28.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1,
changed state to up

R5(config-if)#do ping 141.41.205.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.41.205.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/84 ms
R5(config-if)#

Last part is easy if you know what the task is saying "Configure link control and IP control to predict peer responses." I don't know much about how PPP works, just how to configure the basics, ip addressing and authentication. Here is where context-sensitive help can be of value:

I noticed that ipcp and lcp were options for the ppp command. Let's have a look:

R5(config-if)#ppp lcp ?
(output omitted)
predictive Predict peers LCP requests/replies

R5(config-if)#ppp ipcp ?
(output omitted)
predictive Predict peers IPCP requests/replies

You can see the keyword "predictive" is available for both these commands. This is the answer in fact, but how can we be sure? Let's try the DocCD...Head over the master command list for 12.3. I use 12.3 a lot because they have the old links still working :)

ppp ipcp predictive

ppp lcp predictive

Here is an excerpt from the ppp ipcp entry:

"...set the PPP Internet Protocol Control Protocol (IPCP) to a predictive state that reduces negotiation time by predicting responses from peers and sending expected reply and request packets..."

So here's the commands in action:

R2(config-if)#ppp lcp predictive
R2(config-if)#ppp ipcp predictive

R5(config-if)#ppp lcp predictive
R5(config-if)#ppp ipcp predictive

These tasks seem so easy now. I admit I feel a little rushed and uncomfortable when I get a task that I know I should know but don't really no where to begin. It's all part of the learning process though and it just means I need to study things that I am unfamiliar with.

Review - IPexpert Volume 3 Mock Lab 1

Well I took my first graded mocklab today and got a 41 out of 100. There were a lot of stupid mistakes I made plus a few errors in grading so I feel good about it being my first real full-scale test.

The lab sessions at proctor labs run 7 hours 45 minutes, and I took probably close to a 20 minutes break to eat dinner. Plus I had to load my initial configs and stop early to make sure I saved everything on my desktop for review. I figure I only labbed 7 hours and I didnt attempt the final 3 tasks for 8 points.

Highlights:

Perfect score on QoS (9/9) - 3 tasks. This was very encouraging because after the initial read-through I didn't think I would get it right.

Multicast (4/4) - Only one task but it was over Frame-relay and honestly I never have practiced PIM-SM over NMBA. I knew the commands though and how to troubleshoot multicast in general. I also had a to configure a static mroute and that was the key in the end.

NTP task correct (4/4) - This was tough only because you needed reachability across every network and I skipped most of the redistribution task. It forced me to go back and one-by-one I set up every router to form a server relationship with another, all while tweaking redistribution and crap. The stratum number on every router had to match the router number so you could probably imagine.

IPv6 (3/3) - It was only one task but it was RIP over Frame relay and I had to disable split horizon and map link-local addresses. Just time consuming but I gained confidence in getting it right.

Lowlights:

- Couldnt' get PPP authentication to work so I skipped it just to get full reachability
- Ran out of time for security tasks.
- Had a mess of time getting redistribution to work, mainly because of the mutual redistribution points and the discontiguous area 0 (started with a VL, but ended up with a GRE tunnel)
- Forgot how to TCL script to test full reachability, was gonna cheat but thought "f* it" I dont deserve it :)
-Forgot to finish DHCP snooping configuration by not enabling a trusted port.

Simple mistakes (mine and theirs):

- The results said one of my vtp local updaters was wrong. I checked the IP when I started and it was right. Somewhere it got changed. I should have used the vtp interface command. My bad.

- I used the sdm prefer unicast template which was right, grading script said I was on desktop template. Their bad :) Gimme 3 points. (41+3 = 44)

- Lost 5 points on 2 tasks because I used subinterface s0/1/0.26 while the script looked for s0/1/0.1. The configurations were correct, but the script erred out when it couldn't display .1 Gimme 5 points (44=5=49)

-Didn't turn of auto-summary off in EIGRP on R2. Not required to do so :) Gimme 3 points (49+3 = 52)

- Configured an ACL to only allow 172.20.33.0 - 172.20.47.0 in least amount of config lines and it worked! but the script didn't like my ACL because the I was blocking /32 routes by matching 0.0.0.0. They used 0.0.0.255. These were non-summarized RIP routes anyway and I had all the macthes on my ACL to prove it! (Gimme 3 points 52 + 3 = 55)

- Ping tests failed....er...my bad. I need to learn the TCL ping script...

-There was a BGP aggregation task that worked when I enabled it but for some reason after doing a bunch of other things the routes didn't even show up on the neighbor. I had the commands in the config, but the script checks for the routes. I should have verified...my bad (but I still want the points!)

- My PBR test passed! Theirs didn't for some reason...very weird...Im taking the points...(55+3=58)

Well if I get the VTP thing right and verified BGP better I would have been close to 70, and that was my goal. I feel good though after reading IPExpert's grading script. I know they can't get it perfect but I think they did an excellent job in showing you what they were looking for. I learned that some times it's the result that counts, and sometimes it's the configuration that does.

Anyways, this was my first big assessment. I'm planning on scheduling the real lab for May 2009, whenever those dates become available. Until then its back to the practice lab...

Switching - Dot1q and L2 protocol tunneling

This is a pretty fairly simple lab, but I had never done dot1q tunneling so I wanted to keep it simple.

Network:

[R2 ]---vlan 4---------------[sw1]
[sw1]---asymmetric trunk---[sw2]
[sw2]---dot1q trunk---------[sw3]
[sw3]---asymmetric trunk---[sw4]
[sw4]---vlan 4---------------[R4 ]

Here are the relevant configs with descriptions under the interfaces. Note that the R2 and R4 fastethernet interfaces are on the subnet 192.168.0.0/24.

SW1:
!
interface FastEthernet0/2
description to R2 f0/0
switchport access vlan 4
switchport mode access
!
interface FastEthernet0/12
description to SW2 f0/12
switchport trunk encapsulation dot1q
switchport mode trunk

SW2:
!
interface FastEthernet0/12
description to SW1 f0/12
switchport access vlan 30
switchport mode dot1q-tunnel
!
interface FastEthernet0/23
description to SW3 f0/23
switchport trunk encapsulation dot1q
switchport trunk native vlan 23
switchport mode trunk

SW3:
!
interface FastEthernet0/23
description to SW2 f0/23
switchport trunk encapsulation dot1q
switchport trunk native vlan 23
switchport mode trunk
!
interface FastEthernet0/24
description to SW4 f0/24
switchport access vlan 30
switchport mode dot1q-tunnel

SW4:
!
interface FastEthernet0/4
description to R4 f0/0
switchport access vlan 4
switchport mode access
!
interface FastEthernet0/24
description to SW3 f0/24
switchport trunk encapsulation dot1q
switchport mode trunk

Ping from R2 to R4:

R2#ping 192.168.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/52 ms
R2#

Now let's say I want SW1 and SW4 to see each other as CDP neighbors. And I also want SW1 to be a VTP server and SW4 to be a VTP client.

SW2:

interface FastEthernet0/12
description to SW1 f0/12
l2protocol-tunnel cdp
l2protocol-tunnel vtp

SW3:

interface FastEthernet0/24
description to SW4 f0/24
l2protocol-tunnel cdp
l2protocol-tunnel vtp

Verify CDP tunneling, SW1 and SW4 are NOT directly connected!

SW4:

SW4#show cdp ne

Device ID Local Intrfce Holdtme Capability Platform Port ID
SW1 Fas 0/24 125 R S I WS-C3560-2 Fas0/12
R4 Fas 0/4 132 R 3640 Fas0/0

Verify VTP tunneling:

SW1:

SW1(config)#vlan 13
SW1(config-vlan)#name test

SW4:

SW4#show vtp status | inc Oper
VTP Operating Mode : Client

SW4#show vlan brief | inc 13
13 test active

Pretty cool, eh? That's it for now...

3550 QoS - Trusting, Mapping and Override

Here's the network:

[R2]---[SW3]---[trunk, native vlan 1]---[SW4]---[R4 ]

R2 sets ip-prec to 2:

interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
rate-limit output 16000 8000 8000 conform-action set-prec-transmit 2 exceed-action set-prec-transmit 2

Packet capture show packets still marked when they reach R4 (using Dyngen for routers, binding them to NICs on the PC and then connecting them to the 3550's).

As soon as I enable mls qos on SW3, packets are no longer marked:

SW3(config)#mls qos

To get the 3550 to keep the marking I configure qos trust on the incoming ports:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust

To get the switch to remark the packets, configure cos override:

SW3(config)#int f0/2
SW3(config-if)#mls qos cos override
SW3(config-if)#mls qos cos 4

These packets show up as CS4 on R4. Note that the override command removes the trust command and vice versa:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust

SW3#show run int f0/2
!
interface FastEthernet0/2
switchport mode dynamic desirable
mls qos cos 4
mls qos trust dscp
end

If the trust and "mls qos cos 4" commands exist, the trust takes effect and will not override the DSCP. So the COS4 override mapped to CS4...where does this mapping take place? Here:

SW3#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56

Suppose we want COS4 to be mapped to AF41...which is DSCP 34. We can do this:

SW3(config)#mls qos map cos-dscp ?
<0-63> 8 dscp values separated by spaces
SW3(config)#mls qos map cos-dscp 0 8 16 24 34 40 48 56

Here's part of my wireshark capture in plain text:

Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.2 (192.168.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x88 (DSCP 0x22: Assured Forwarding 41; ECN: 0x00)
1000 10.. = Differentiated Services Codepoint: Assured Forwarding 41 (0x22)

Ok here's an interesting one: what happens if I configure QoS on SW4 and set it to trust the COS instead of the DSCP value?

SW4(config)#int f0/24
SW4(config-if)#mls qos trust ?
cos Classify by packet COS
device trusted device class
dscp Classify by packet DSCP
ip-precedence Classify by packet IP precedence

SW4(config-if)#mls qos trust cos

It remarks the packet to CS4 based on the cos-dscp map, of course!

IPv6 - link local address, MAC to EUI-64 conversion

The fastest way to get a link local address is to configure an interface with the ipv6 enable command. For example:

R1(config)#int f0/0
R1(config-if)#ipv6 enable

What will the link local address be? Before we take a look, let's figure it out ourselves. First do a show interface:

R1#show int f0/0 | in add
Hardware is Gt96k FE, address is c200.0854.0000 (bia c200.0854.0000)
R1#

To convert this MAC address to a link-local using eui-64 format do the following:

1. MAC Address: c200.0854.0000
2. Insert FFFE in the middle: c200:08FF:FE54:0000
3 Flip the U/L bit: 7th bit from the left: c000:08FF:FE54:0000
4. Append the prefix FE80: FE80::c000:08FF:FE54:0000
5. Remove extra 0's: FE80::C000:8FF:FE54:0

Let's take a look:

R1#show ipv6 interface f0/0 | in link
IPv6 is enabled, link-local address is FE80::C000:8FF:FE54:0

BGP - TTL security

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.

Example:

On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5

After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytes

The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251
R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5

After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

You can verify like this:

R6#show ip bgp neighbors 172.14.45.5 | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255

I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.

BGP - local-as option

BGP local-as option allows a router to appear as if it is in another AS. Suppose we have a frame-relay cloud with 3 routers all EBGP peers with each other:

R6: 172.14.45.6 (AS 65000)
R5: 172.14.45.5 (AS 65005)
R4: 172.14.45.4 (AS 345)

We can configure R6 to use the local-as option to appear to be from AS 65006 to R5, but remain in AS65000 for R4. Here's how:

R6(config-router)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006

On R5:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65006

Let's take a look at the neighbor summary:

R5# show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 220 221 244 0 0 00:03:39 9

R4#show ip bgp summary | be Ne
172.14.45.6 4 65000 176 146 69 0 0 00:00:08 11

Notice the different AS numbers. Also notice the AS path from R5's view:

R5# show ip bgp | inc 172.14.45.6
*> 6.0.3.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 65000 i

And the AS path from R6's view also includes the local-AS number:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65006 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65006 65005 i

The routes appear to magically pass through 65006. We can prevent R6 from prepending the local-as number on routes received from R6 with the no-prepend option

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend

65006 is no longer in the AS Path:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65005 i

With the replace-AS we can prevent R5's real BGP AS number from appearing in the AS path on routes from R6 to R5:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as

R5# show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 6.0.3.0/24 172.14.45.6 0 0 65006 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 i

Lastly, we can configure R6 to accept connections to either AS 65000 or AS 65006 with the dual-as option:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as dual-as

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 268 284 343 0 0 00:00:08 9

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65000
R5(config-router)#
.Jul 14 21:34:34.273: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Remote AS changed
R5(config-router)#
.Jul 14 21:34:36.505: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
R5(config-router)#
R5(config-router)#^Z
R5#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 270 286 0 0 0 00:00:09 0

BGP - maximum-prefix command

The network:

[R5]---[R6]

R5 connects to R6 via EBGP
R5 is 172.14.45.5
R6 is 172.14.45.6

R6 is advertising 10 networks to R5:

R5#show ip bgp | inc 45\.6
*> 6.0.0.0/24 172.14.45.6 0 0 65000 i
*> 6.0.1.0/24 172.14.45.6 0 0 65000 i
*> 6.0.2.0/24 172.14.45.6 0 0 65000 i
*> 6.0.3.0/24 172.14.45.6 0 0 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65000 i
*> 6.0.6.0/24 172.14.45.6 0 0 65000 i
*> 6.0.7.0/24 172.14.45.6 0 0 65000 i
*> 6.0.8.0/24 172.14.45.6 0 0 65000 i
*> 6.0.9.0/24 172.14.45.6 0 0 65000 i

I am going to play with a few options of the maximum-prefix command and see the effect. First let's configure a maximum of 8 routes:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8
R5(config-router)#
.Jul 14 20:45:41.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Maximum-Prefix restart timeout
.Jul 14 20:46:10.519: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:46:11.919: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:46:11.927: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:46:11.931: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:46:11.931: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
R5(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0058 0200 0000 1940 0
101 0040 0204 0201 FDE8 4003 04AC 0E2D 0680 0404 0000 0000 1806 0009 1806 0008 1
806 0007 1806 0006 1806 0005 1806 0004 1806 0003 1806 0002 1806 0001 1806 0000

Notice that the nighbor tried to come up after I configured the max. It never tried to come up again after going down the second time. Now the neighbor has the following output (much of the output is omitted):

R5#show clock
.20:50:26.655 UTC Mon Jul 14 2008
R5#

R5#show ip bgp neighbor 172.14.45.6
...
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 8
Threshold for warning message 75%
Reduce the no. of prefix and clear ip bgp 172.14.45.6 to restore peering

We can also configure the router to try and establush the connection again after the max limit is reached and the connection is brought down:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 restart 1

Here is a sample of the output, the connection tries to re-establish but then drops because the max-prefix limit is reached:

R5#
.Jul 14 20:53:16.779: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:53:16.811: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:53:16.819: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:53:16.823: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:53:16.827: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:54:15.999: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:54:16.011: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:54:16.015: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:54:16.023: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:54:16.023: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:55:41.311: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:55:41.355: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:55:41.359: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:55:41.363: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:55:41.367: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes

We can also configure a percentage to give us a warning. Here we configure the percantge to 75 of 8 (6) while disabling 3 of the loopbacks on R6:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 7

.Jul 14 21:00:08.226: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 21:00:08.234: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8

The connection stays up:

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 186 177 224 0 0 00:00:33 7

Lastly, we can configure a warning-only which doesn't bring down the connection:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 75 warning-only

.Jul 14 21:01:53.614: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 8, max 8
.Jul 14 21:02:24.046: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8

The connection stays up:

R5#show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 190 181 226 0 0 00:02:41 9

This was a quick and dirty blog. Hopefully by reading this every now and then you get an idea about how the max-prefix option works.

BGP - deterministic-med and always-compare-med

The inspiration for this blog was directly from here:

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

In order to get the various routes to look right in the bgp table, it took some work. Here is a picture that helps explain it. I'm not gonna put addressing on it. If you want configs, let me know.


Our focus is on R1, it has 3 bgp entries to 3.3.3.0:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 24
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
R1#

Tiebreaker:
1. entry1 and entry2 are compared, entry2 is picked because external > internal
2. entry2 and entry3 are compared, entry 3 picked because RID 3.3.3.3

Now let's configre always-compare-med:

R1(config)#router bgp 65000
R1(config-router)#bgp always-compare-med

This command should allow entry1 to be picked over entry2 (lower MED), then entry1 will be preferred over entry3 (also lower MED):

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 41
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external

It works!

Notice that entries are compared in pairs. To get the pairs reordered you may have shut peers down and enable them accordingly. Example: I wanted the peers to appear in this order 4.0.3.4, 3.3.3.3, and 2.2.2.2. So I brought them up in reverse order: 2.2.2.2, 3.3.3.3, and finally 4.0.3.4. I just did a shut/no shut on the interface. Now I have:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 47
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best

Notice the best route is still from 2.2.2.2 because always-compare-med is enabled. Let's try bgp deterministic-med, without always compare-med. First reset bgp, then continue.

R1(config)#router bgp 65000
R1(config-router)#no bgp always-compare-med
R1(config-router)#bgp deterministic-med

In this case entry2 should be compared to entry3 with entry 2 winning based on lower MED (they are in the same AS so MED is compared). Then entry2 is compared to entry1, with entry1 winning because external bgp is preferred over internal. MED is not compared between these entries.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 11
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

Notice in the above example that the entries are ordered in groups based on AS. I brough up 4.4.4.4 last, but it is showing up last with the other entry from AS400.

The last example uses both bgp deterministic-med and bgp always-compare-med. In this case, entry2 should win with the lowest MED. This is the same as the last example except MED is used for comparison between entry1 and entry2.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 12
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

Sweet!

BGP - set clauses are ignored on reflected routes

Network:

R4,R5,R6 have serial interfaces connected to Frame cloud 172.14.45.0/24
R3,R4,R5 have LAN interfaces connected to 172.12.34.0/24

R6 has EBGP peering with R5 and R4, however R5 has R6 neighbor shutdown for now.
R4 is connected to R5 via IBGP.
R5 then connects to R3 via IBGP.
R5 has R3 configured as a route-reflector client.
R5 reflects routes learned from R4 to R3.
R5 has the following config:

router bgp 345
bgp cluster-id 5
neighbor 3.3.3.3 remote-as 345
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 route-map SET out
!
ip prefix-list SIX seq 5 permit 6.0.0.0/24
!
route-map LOOPBACK permit 10
match ip address 5
!
route-map SET permit 10
match ip address prefix-list SIX
set community 500
!
route-map SET permit 20
!

The community does not show up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

Now let's peer R5 directly with R6 and see what happens:

R5(config)#router bgp 345
R5(config-router)#neighbor 4.4.4.4 shutdown
R5(config-router)#no neighbor 172.14.45.6 shutdown

Immediately the community shows up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 13
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
65000
172.14.45.6 (inaccessible) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 200, localpref 100, valid, internal
Community: 500

I got this info while browsing the DocCD:

Configuring a Route Reflector

"The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers."

BGP - changing cluster-id

The network:

[R3]---[R5]---[R4]---[EXTERNAL AS]

R3 is IBGP peer with R5
R5 is IBGP peer with R4
R5 is the route reflector

Here is the bgp entry for a route learned initially from R4:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 5.5.5.5

Changing the cluster-id:

R5(config)#router bgp 345
R5(config-router)#bgp cluster-id ?
<1-4294967295> Route-Reflector Cluster-id as 32 bit quantity
A.B.C.D Route-Reflector Cluster-id in IP address format
R5(config-router)#bgp cluster-id 5

Here's how the change looks on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

BGP - prefix-based outbound route filtering

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.

In this example we have EBGP peers R4 and R3:

[R4]---[R3]

R3 is receiving a bunch of routes from R4:

R3#show ip bgp Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i
*> 4.0.1.0/24 172.12.34.4 0 0 400 i
*> 4.0.2.0/24 172.12.34.4 0 0 400 i
*> 4.0.3.0/24 172.12.34.4 0 0 400 i

R3 only wants to receive 3 routes:

1.0.0.0/24
2.0.0.0/24
4.0.0.0/24

R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send

R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receive

Now configure the prefix-list and apply it to the neighbor:

R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24
R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24
R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24
R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO in

R3#clear ip bgp * soft in prefix-filter

Here is the final result:

R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i

Here are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?



Restrictions:

I used the bgp upgrade-cli command to configure these neighbors in AF mode.
Also, prefix-lists must be used, not ACL or distribute lists

For more info go here:

BGP Prefix-Based Outbound Route Filtering