misc: optimzation in the layout of the blog labs

Hi everybody!

I recognized that my scenarios with the cisco specific outputs the output mostly looked like crap.

This way:

Router#sh 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
C 1.1.1.1 is directly connected, Loopback0
Router#

This was due to the fact that I did not use the right operator in the text mode of wordpress. I used the “code” value and not “code” in combination with “pre”. With that combination it looks better now!


Router#sh 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
C       1.1.1.1 is directly connected, Loopback0
Router#

So in the future posts there will be more comfort for you!

Regards!
Markus

Posted in Misc, Uncategorized | Tagged , , , , , , , , , , , , , | 1 Comment

mpls: pseudowire emulation / any tansport over mpls – interconnecting sites via layer 2 – (part 2)

Hi again!
Now its time for part 2 of the MPLS Layer 2 interconection between two sites.

Challenge:
– interconnect two sites via PEM but without an MPLS enabled service provider network

Preconfigured & given:
– topology of Part 1
– CORE routers dont run MPLS on their backbone interfaces

So here we go. First we deconfigure MPLS from the core routers and check if everything is the way we want it to.

CORE1(config)#int fa0/0
CORE1(config-if)#no mpls ip
!
CORE2(config)#int fa0/0
CORE2(config-if)#no mpls ip
CORE2(config)#int fa0/1
CORE2(config-if)#no mpls ip
!
CORE3(config)#int fa0/0
CORE3(config-if)#no mpls ip

CORE2#sh mpls int
Interface IP Tunnel Operational

No output for the MPLS switching! Perfect! So now we are sure that CORE2 will definitely dont do any MPLS forwarding.
Now we want to use ATOM/PEM, but the problem is that this technology relies on MPLS. Hm…so what are we going to do now. Well…lets use a GRE tunnel to do that. The tunnel is built between the loopbacks of CORE1 and CORE3.

CORE1(config)#int tun 0
CORE1(config-if)#tunnel mode gre ip
CORE1(config-if)#tunnel source lo0
CORE1(config-if)#tunnel destination 3.3.3.3
CORE1(config-if)#ip address 13.13.13.1 255.255.255.252
!
CORE3(config)#int tun0
CORE3(config-if)#tunnel mode gre ip
CORE3(config-if)#tunnel source lo0
CORE3(config-if)#tunnel destination 1.1.1.1
CORE3(config-if)#ip address 13.13.13.2 255.255.255.252

Check if the tunnels are working!

CORE3#ping 13.13.13.1 so tun0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.13.13.1, timeout is 2 seconds:
Packet sent with a source address of 13.13.13.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/136/156 ms
CORE3#

Fine! So as any traffic going through the tunnel interfaces is encapsulated in GRE, well LDP should be as well. We now activate LDP on those two interfaces

CORE1(config)#int tun0
CORE1(config-if)#mpls ip
!
CORE3(config)#int tun0
CORE3(config-if)#mpls ip

So far so good lets check the neighbors and the interfaces.

CORE3#sh mpls ldp neigh
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
TCP connection: 1.1.1.1.646 - 3.3.3.3.17830
State: Oper; Msgs sent/rcvd: 11/11; Downstream
Up time: 00:00:21
LDP discovery sources:
Tunnel0, Src IP addr: 13.13.13.1
Addresses bound to peer LDP Ident:
172.16.21.1 1.1.1.1 13.13.13.1
CORE3#sh mpls int
Interface IP Tunnel Operational
Tunnel0 Yes (ldp) No Yes

Ok looking good. So now we will try to do “xconnect” the two tunnel inteface addresses.

CORE1(config)#int fa0/1
CORE1(config-if)#xconnect 13.13.13.2 12 pw-class PWC-SITE-1-2
!
CORE3(config)#int fa0/1
CORE3(config-if)#xconnect 13.13.13.1 12 pw-class PWC-SITE-1-2

As we configure it we get an error message that says:

*Mar 1 03:02:07.303: %ATOM_TRANS-4-CONFIG: 13.13.13.1 mismatches the peer router id 1.1.1.1

Well the Problem is that in general the highest loopback is chosen as LDP router-id. ATOM needs to connect to the router-id ip address (at least thats my point of knowledge). And the tunnel ip address is not equal to the router-id. Well you could change that with the “mpls ldp router-id tunnel0 force” command but the problem is that when you use that in production network you can get into trouble. Here you should create a new loopback address, lets say Lo1 and then for all PEM/ATOM connections use that IP address with static routing over the tunnels. Well lets just do this.

CORE1(config)#int lo1
CORE1(config-if)#ip address 11.11.11.11 255.255.255.255
CORE1(config-if)#mpls ldp router-id lo1 force
!
CORE3(config)#int lo1
CORE3(config-if)#ip address 33.33.33.33 255.255.255.255
CORE3(config-if)#mpls ldp router-id lo1 force

NOTE: When changing the router-id, all LDP neighbor relationships will go down! Keep that in mind when you are going to do this in a production network.

Goal of this step was to create loopback addresses that can be used for creating xconnect peerings AND that traffic should go through the tunnel interface. so lets create static routes here.

CORE1(config)#ip route 33.33.33.33 255.255.255.255 tun0
!
CORE3(config)#ip route 11.11.11.11 255.255.255.255 tun0

Reachability check!

CORE3#ping 11.11.11.11 so lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
Packet sent with a source address of 33.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/129/236 ms

Looking good. So next step is to reconfigure the xconnect statements.

CORE1(config)#int fa0/1
CORE1(config-if)#no xconnect 13.13.13.2 12
CORE1(config-if)#xconnect 33.33.33.33 12 pw-class PWC-SITE-1-2
!
CORE3(config)#int fa0/1
CORE3(config-if)#no xconnect 13.13.13.1 12
CORE3(config-if)#xconnect 11.11.11.11 12 pw-class PWC-SITE-1-2

Give it some time to converge and then check the VC details.

CORE1#sh mpls l2transport vc

Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa0/1 Ethernet 33.33.33.33 12 UP

Looks good! Lets do a basic ICMP test with standard size and then lets have a look at the additional headers we created.

SITE1#ping 10.10.10.2 rep 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 52/135/236 ms

Cool it works. When we capture the traffic between CORE1 and CORE2 we should see GRE encapsulated traffic as MPLS is disabled on CORE2.

As we can see there is an additional GRE header which also takes space (4 Byte) and as GRE is an IP encapsulation technology, the frames dont get encapsulated directly into MPLS. Everything that goes through the tunnel is encapsulated into an IP packet so here we get another 20Bytes.

Well as you can see there is only one MPLS header! Guess why! Penultimate Hop Popping (PHP) is in use per default. And as we only have one hop here (between the tunnel endpoints) there is no need for a outer transport label! So you can only see the VC label.

Lets count everything together to calculate the required MTU size of the backbone interfac
es.

The new L2 payload size (MTU) for our backbone interfaces is therefore 20 + 4 + 4 + 14 + 1500 + 4 = 1546 Bytes. Lets try this now.

CORE1(config)#int fa0/0
CORE1(config-if)#mtu 1546
!
CORE2(config)#int fa0/0
CORE2(config-if)#mtu 1546
CORE2(config-if)#int fa0/1
CORE2(config-if)#mtu 1546
!
CORE3(config)#int fa0/0
CORE3(config-if)#mtu 1546

Take some time to let ISIS reconverge.

SITE1#ping 10.10.10.2 rep 10 size 1500 df

Type escape sequence to abort.
Sending 10, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 100/165/208 ms

Works!
So have fun with that scenario and feel free to comment!

Regards!
Markus

Posted in MPLS | Tagged , , , , , , , , , , , , , | Leave a comment

mpls: pseudowire emulation / any tansport over mpls – interconnecting sites via layer 2 – (part 1)

Hi everybody!
Today I am going to introduce a new challenge that takes care of MPLS and pseudowire emulation.

Challenge:
– connect two sites via a MPLS VPN Backbone at layer 2

Given:
– a “SP” network without MPLS capabilities (yet), only layer 3 routing

Preconfigured:
– ip addresses of the core routers
– ISIS as routing protocol for routing the 172.16.x.x networks and the loopback interfaces

So lets start:
First of all we do a quick routing table lookup on the core routers to see if we have full rechability between the loopbacks of the cores.

CORE3#ping 1.1.1.1 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.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 = 56/75/124 ms
CORE3#ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/59/92 ms
CORE3#

CORE3#sh 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
i L1 1.1.1.1 [115/30] via 172.16.32.1, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
i L1 2.2.2.2 [115/20] via 172.16.32.1, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.32.0 is directly connected, FastEthernet0/0
i L1 172.16.21.0 [115/20] via 172.16.32.1, FastEthernet0/0

Looks good. Next step is choosing the technology we want to use. In our case we will use “pseudowire emulation” or “any transport over mpls” or whatever it is called :).
That technology requires MPLS to be enabled within the service provider network. So we will do this.

NOTE: We dont need MP-BGP here, because PEM (pseudowire emulation) only needs traffic to be encaspulated into MPLS to be transported end to end. There is no need for exchanging VRF information over BGP extended communities.


CORE1(config-if)#mpls ip
CORE1(config-if)#
!
CORE2(config)#int fa0/0
CORE2(config-if)#mpls ip
CORE2(config-if)#int fa0/1
CORE2(config-if)#mpls ip
!
CORE3(config)#int fa0/0
CORE3(config-if)#mpls ip

On Core 2 we will do a lookup into the LDP neighbor table to see if the adjacencies have been built.

CORE2#sh mpls int
Interface IP Tunnel Operational
FastEthernet0/0 Yes (ldp) No Yes
FastEthernet0/1 Yes (ldp) No Yes
CORE2#sh mpls ldp neigh
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
TCP connection: 1.1.1.1.646 - 2.2.2.2.47369
State: Oper; Msgs sent/rcvd: 9/9; Downstream
Up time: 00:01:21
LDP discovery sources:
FastEthernet0/0, Src IP addr: 172.16.21.1
Addresses bound to peer LDP Ident:
172.16.21.1 1.1.1.1
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
TCP connection: 3.3.3.3.43937 - 2.2.2.2.646
State: Oper; Msgs sent/rcvd: 8/8; Downstream
Up time: 00:00:54
LDP discovery sources:
FastEthernet0/1, Src IP addr: 172.16.32.2
Addresses bound to peer LDP Ident:
172.16.32.2 3.3.3.3

Looks good! Messages have been exchanged between the machines.
Now we will create a “pseudowire class” to set the method (in our case MPLS) which should be used to encapsulate packets.

NOTE: we only need to perform this step on the ingress and egress routers (where the emulation takes place). All other routers only need to perform label switching.

CORE1(config)#pseudowire-class PWC-SITE-1-2
CORE1(config-pw-class)#encapsulation mpls
!
CORE3(config)#pseudowire-class PWC-SITE-1-2
CORE3(config-pw-class)#encapsulation mpls

Now we are going to use those ones with the “xconnect” command under the interfaces we want to have a Layer2 connection with each other. This will be fa0/1 of CORE1 and CORE3.
Under the interface level we also need to type in an ip address. Well kind of strange but that is atually the ip address of the peering router that has the other side of the “virtual L2 line” in his stack. What makes sense here is to enter the loopback interface of the corresponding machines.

CORE1(config-if-xconn)#int fa0/1
CORE1(config-if)#xconnect 3.3.3.3 12 pw-class PWC-SITE-1-2
!
CORE3(config-if-xconn)#int fa0/1
CORE3(config-if)#xconnect 1.1.1.1 12 pw-class PWC-SITE-1-2

What now is heading into our eyes is another LDP neighborship?!?!

*Mar 1 00:21:36.015: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP

Well what the hell is this about? Well that is a targeted hello session that is needed to exchange pseudowire information between the two corresponding routers. Background to that matter is the following: The routers form a LDP adjacency via unicast. Reason for that is that they need to talk to each other about the MPLS header for the VC (the pseudowire virtual channel) as the packets are first sent from CORE1 to CORE3 via MPLS (the transport label) and then the transport label is stripped of. The second label then gives information about the corresponding VC.

The config is done right now! Now we gotta check if the VC (virtual channel) is up.
NOTE: Here you can also see the “MPLS VC Labels” that have been exchanged between CORE1 and CORE3. So dont wonder when you are sniffing the MPLS packets and see the labels 19 and 20 show up in your wireshark output and they dont when doing a “sh mpls ldp binding”.

CORE3#sh mpls l2transport vc det
Local interface: Fa0/1 up, line protocol up, Ethernet up
Destination address: 1.1.1.1, VC ID: 12, VC status: up
Next hop: 172.16.32.1
Output interface: Fa0/0, imposed label stack {18 19}
Create time: 00:08:01, last status change time: 00:07:59
Signaling protocol: LDP, peer 1.1.1.1:0 up
MPLS VC labels: local 20, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 57, send 57
byte totals: receive 6253, send 6253
packet drops: receive 0, seq error 0, send 0
!CORE1#sh mpls l2transport vc det
Local interface: Fa0/1 up, line protocol up, Ethernet up
Destination address: 3.3.3.3, VC ID: 12, VC status: up
Next hop: 172.16.21.2
Output interface: Fa0/0, imposed label stack {19 20}
Create time: 00:29:18, last status change time: 00:08:21
Signaling protocol: LDP, peer 3.3.3.3:0 up
MPLS VC labels: local 19, remote 20
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 191, send 189
byte totals: receive 21087, send 20924
packet drops: receive 0, seq error 0, send 10

Nice! Seems to look good. We will now configure some ip addresses on the routers SITE1 and SITE2 to see if we can get an L2 adjacency.

SITE1(config)#int fa0/0
SITE1(config-if)#ip add 10.10.10.1 255.255.255.0
!
SITE2(config)#int fa0/0
SITE2(config-if)#ip add 10.10.10.2 255.255.255.0

Lets try a simple icmp.

SITE1#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/131/200 ms
SITE1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 - c20e.1164.0000 ARPA FastEthernet0/0
Internet 10.10.10.2 27 c20d.1aac.0000 ARPA FastEthernet0/0

It succeeds. Well thats good :). Lets see if we can use other layer 2 protocols.

SITE1#sh cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE1 Fas 0/0 127 R S I 3725 Fas 0/1
SITE2 Fas 0/0 142 R S I 3725 Fas 0/0

Ok thats enough for now! We can see that it works. But we will test something else now. A ping with the payload of 1500 (including ip header) between the two sites with the DF bit set.

SITE1#ping 10.10.10.2 size 1500 df

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

FAIL! Thats not what we wanna see. We want to use 1500bytes of mtu but we cant. Well, the reason for that is the additional headers we have used to generate the PEM. Lets do some wireshark action here. We will sniff the icmp packets between CORE1 and CORE2 to see whats happening. First we will get some packets with the standard icmp size and not with 1500 DF.

Well there is the problem, we have a little more traffic to handle with the PEM.

1x MPLS Label for transporting the packet through the MPLS network to the PEM peer (4 Byte)
1x MPLS Label that is used at the peer for identifying the correct VC (4 Byte)
1x additional Ethernet Header. Well our source frame from SITE1 is 1518 bytes long. As the COMPLETE frame is encapsulated into two MPLS headers and we are using ethernet as transport technology here, means that there needs to be a new L2 header for transporting the frame from CORE1 to CORE2 and so on (18 Byte).

So this is the initial frame that SITE1 wants to send to SITE2 (Payload/required MTU is 1500):

And this is the packet when it was encapsulated by PEM and goes on its way into the backbone (New Payload/required MTU is now 1526 Byte):

Lets configure the new required MTU.

NOTE: When changing the MTU and within the backbone the MTU on some links is different, then you wont get an OSPF or ISIS adjacency as the MTU is part of the negotiation process for such relationships.

CORE1(config-if)#mtu 1526
CORE1(config-if)#
!
CORE2(config-if)#int fa0/0
CORE2(config-if)#mtu 1526
CORE2(config-if)#int fa0/1
CORE2(config-if)#mtu 1526
!
CORE3(config)#int fa0/0
CORE3(config-if)#mtu 1526

Give ISIS or OSPF some time to reconverge if needed and then you can head on with the ICMP testing.

SITE1#ping 10.10.10.2 rep 5 size 1500 df

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/160/204 ms

It works!!!

Read the next part coming up where we will do the same with the exception that the provider network (CORE2) is not capable of MPLS :).

Have fun and feel free to comment!

Regards!
Markus

Posted in MPLS, Uncategorized | Tagged , , , , , , , , , , , , , , , , | 2 Comments

mpls: simple and advanced inter-vrf routing/leaking

Hello everybody!
Today I will spend some time in demonstrating how to route between separate VRF instances on a local router.

Special prerequisites:
– Understanding of VRF lite

Topology:

Our topology exists of three routers. Quite simple for the beginning but I think with a little bit of configuring we can get this scenario a little more complex ;).

Given configuration:
– routers R2 and R3 are connected via a FastEthernet link to R1
– all routers have loopback addresses configured

Challenge #1:
– R2 and R3 shall use R1 as the default router (to reach the Loopback of the router on the other end)

Challenge #2:
– put the connection to both R2 and R3 in different VRFs on R1 BUT they still should be able to reach each other (first solution with static routing, second one with dynamic routing but everything is done on R1)

So lets begin!

Challenge #1:
First of all we need to (as we are using static routing in our case) configure R1 to be able to reach the loopbacks of R2 and R3.

R1(config)#ip route 2.2.2.2 255.255.255.255 172.16.21.2
R1(config)#ip route 3.3.3.3 255.255.255.255 172.16.31.2

Of course we need to configure the reverse route on R2 and R3 in order to establish bidirectional connectivity. As the task requires to configure a default route we will configure such a route.

R2(config)#ip route 0.0.0.0 0.0.0.0 172.16.21.1

R3(config)#ip route 0.0.0.0 0.0.0.0 172.16.31.1

Lets test the ICMP reachability.

R1#ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/45/88 ms
R1#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/50/100 ms
R1#

Works prefectly. Lets now check end to end connectivity between R2 and R3

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/94/128 ms

Also fine! Challenge one is completed.

Challenge #2:
We will now create two new VRFs (VRF_R2 and VRF_R3) on R1 in order to put the connections into different VRFs.



R1(config)#ip vrf VRF_R2
R1(config-vrf)#rd 2:2
R1(config-vrf)#route-target both 2:2
R1(config-vrf)#ip vrf VRF_R3
R1(config-vrf)#rd 3:3
R1(config-vrf)#route-target both 3:3

Lets put the interfaces fa0/0 and fa0/1 in the corresponding VRFs.

R1(config-vrf)#int fa0/0
R1(config-if)#ip vrf for VRF_R2
% Interface FastEthernet0/0 IP address 172.16.21.1 removed due to enabling VRF VRF_R2
R1(config-if)#ip address 172.16.21.1 255.255.255.252
R1(config-if)#int fa0/1
R1(config-if)#ip vrf for VRF_R3
% Interface FastEthernet0/1 IP address 172.16.31.1 removed due to enabling VRF VRF_R3
R1(config-if)#ip address 172.16.31.1 255.255.255.252

Never forget to verify the config!

R1#sh ip vrf
Name Default RD Interfaces
VRF_R2 2:2 Fa0/0
VRF_R3 3:3 Fa0/1

Looks quite good here! Then lets try the connectivity from the VRFs of R1 to the Loopback of R2 and R3.

R1#ping vrf VRF_R2 2.2.2.2

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

Strange…does not work. But why? Lets check the routing table of the VRFs.

R1#sh ip route vrf VRF_R2

Routing Table: VRF_R2
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

172.16.0.0/30 is subnetted, 1 subnets
C 172.16.21.0 is directly connected, FastEthernet0/0
R1#sh ip route vrf VRF_R3

Routing Table: VRF_R3
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

172.16.0.0/30 is subnetted, 1 subnets
C 172.16.31.0 is directly connected, FastEthernet0/1

No static routes?! Well that makes sense as we configured the static routes earlier for the global routing table and not for the specific VRFs. We have to correct that.

R1(config)#no ip route 2.2.2.2 255.255.255.255 172.16.21.2
R1(config)#no ip route 3.3.3.3 255.255.255.255 172.16.31.2
R1(config)#ip route vrf VRF_R2 2.2.2.2 255.255.255.255 172.16.21.2
R1(config)#ip route vrf VRF_R3 3.3.3.3 255.255.255.255 172.16.31.2

Lets have a look at the RTs now!

R1#sh ip route vrf VRF_R2

Routing Table: VRF_R2
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

2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 172.16.21.2
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.21.0 is directly connected, FastEthernet0/0
R1#sh ip route vrf VRF_R3

Routing Table: VRF_R3
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

3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 172.16.31.2
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.31.0 is directly connected, FastEthernet0/1

Looks better now. And the following ICMP check too!

R1#ping vrf VRF_R2 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/43/72 ms
R1#ping vrf VRF_R3 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/33/72 ms

Lets now check end to end connectivity between R2 and R3.

R2#ping 3.3.3.3 so lo0

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

Interesting…does not work. But instead of just dotting the ping out…the router gives us a “U” back. This means that the next-hop or what hop ever sends an ICMP unreachable back informing us that the router we have sent the packet to doesnt have a route for the destination prefix. This is quite logical here because R1 has no route for 3.3.3.3/32 in its routing table for VRF_R2. So we need to tune this a little and need to configure a leak between those VRFs. We will generate a static route in a VRF that is pointing to a different VRF. Sounds quite strange but it works, as the router connects the VRFs we are giving him by one -> the name of the VRF we are adding the static route and second -> the VRF the gateway address is participating in.

R1(config)#ip route vrf VRF_R3 2.2.2.2 255.255.255.255 fa0/0 172.16.21.2
R1(config)#ip route vrf VRF_R2 3.3.3.3 255.255.255.255 fa0/1 172.16.31.2

Lets check the tables. Take a look at the routes. I specified an interface AND the gateway ip address. This is necessary because if you only specify the gateway the router looks for this address in the specific vrf, doesnt find it and so does not create the route. When you specify also the interface the router now knows that you wanna route-leak as the interface is in a different vrf and then searches or the following ip address in the vrf of the destination interface.

R1#sh ip route vrf VRF_R2

Routing Table: VRF_R2
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

2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 172.16.21.2
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 172.16.31.2, FastEthernet0/1
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.21.0 is directly connected, FastEthernet0/0
R1#sh ip route vrf VRF_R3

Routing Table: VRF_R3
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

2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 172.16.21.2, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 172.16.31.2
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.31.0 is directly connected, FastEthernet0/1

There we go. Looks good. Lets now check the end-to-end reachbility again.

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/71/104 ms

We made it!

Next step we will do is to…well…solve this a little more dynamic. Imagine that there are lots of disjunct networks you want to connect. Then you are running into the problem that you need a new keyboard after some times because you typed millions of static routes :).
Or protocol of choice in that case is BGP, better MP-BGP. Thats because MP-BGP is capable of handling VRF and so VPN information protocol wide, not only local.

First of all we will remove the static inter-VRF routes from R1.

R1(config)#no ip route vrf VRF_R2 3.3.3.3 255.255.255.255 FastEthernet0/1 172.16.31.2
R1(config)#no ip route vrf VRF_R3 2.2.2.2 255.255.255.255 FastEthernet0/0 172.16.21.2

Lets check if the end-to-end connectivity is broken.

R2#ping 3.3.3.3 so lo0

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

Ok so far so good. Now we are going to activate MP-BGP by enabling BGP on the router.

R1(config)#router bgp 65000
R1(config-router)#no auto
R1(config-router)#no sync

MP-BGP has the capability of handling different VRFs by using so called address-families. We will now create an address family for each VRF.

R1(config-router)#address-family ipv4 vrf VRF_R2
R1(config-router-af)#address-family ipv4 vrf VRF_R3

Okay. Well what we now have is to torn it down…one BGP instance for the same AS in different VRFs on the router. You recognize its getting a little more complex now :). Every VRF uses (when its transported or better advertised via BGP) route-targets. Those little route-targets are used to tag a bgp routes extended community string. Let me show you this a little bit more on the router. Its easier to explain here.

R1#sh run | sec vrf
ip vrf VRF_R2
rd 2:2
route-target export 2:2
route-target import 2:2
ip vrf VRF_R3
rd 3:3
route-target export 3:3
route-target import 3:3

That means when routes (which we created statically) are sent into the BGP process they are tagged with the extended community 2:2 or 3:3…this is what route-target export means. Route-Target import means that routes coming from BGP peers or locally injected BGP routes (this is what we will abuse) are imported into the VRF routing table/routing processes.
what we will now do…well we want the static route of VRF_R2 in the RT of VRF_R3 and vice versa, but without a static route. Well we first need to import the routes of the opposite VRF.

R1(config)#ip vrf VRF_R2
R1(config-vrf)#route-target import 3:3
R1(config-vrf)#ip vrf VRF_R3
R1(config-vrf)#route-target import 2:2

Okay lets have a look.

R1#sh ip route vrf VRF_R2

Routing Table: VRF_R2
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

2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 172.16.21.2
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.21.0 is directly connected, FastEthernet0/0

Hmm nothing there but why? Remember that we wanna use BGP as the leaking method here. So we first need to handover those static routes into the BGP process, so that BGP can handover the routes between the two VRFs.

R1(config)#router bgp 65000
R1(config-router)#address-family ipv4 vrf VRF_R2
R1(config-router-af)#redistribute static
R1(config-router-af)#redistribute connected
R1(config-router-af)#address-family ipv4 vrf VRF_R3
R1(config-router-af)#redistribute static
R1(config-router-af)#redistribute connected

Lets check if BGP has the routes in its routing-process (by the way I also redistributed the connected interfaces to get full convergence of the link addresses as well).

R1#sh ip bgp vpnv4 all
BGP table version is 13, local router ID is 1.1.1.1
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: 2:2 (default for vrf VRF_R2)
*> 2.2.2.2/32 172.16.21.2 0 32768 ?
*> 3.3.3.3/32 172.16.31.2 0 32768 ?
*> 172.16.21.0/30 0.0.0.0 0 32768 ?
*> 172.16.31.0/30 0.0.0.0 0 32768 ?
Route Distinguisher: 3:3 (default for vrf VRF_R3)
*> 2.2.2.2/32 172.16.21.2 0 32768 ?
*> 3.3.3.3/32 172.16.31.2 0 32768 ?
*> 172.16.21.0/30 0.0.0.0 0 32768 ?
*> 172.16.31.0/30 0.0.0.0 0 32768 ?

Looks quite good, lets check the RTs.

R1#sh ip route vrf VRF_R2

Routing Table: VRF_R2
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

2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 172.16.21.2
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 172.16.31.2 (VRF_R3), 00:01:27
172.16.0.0/30 is subnetted, 2 subnets
B 172.16.31.0 is directly connected, 00:01:27, FastEthernet0/1
C 172.16.21.0 is directly connected, FastEthernet0/0
R1#sh ip route vrf VRF_R3

Routing Table: VRF_R3
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

2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [20/0] via 172.16.21.2 (VRF_R2), 00:01:44
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 172.16.31.2
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.31.0 is directly connected, FastEthernet0/1
B 172.16.21.0 is directly connected, 00:01:31, FastEthernet0/0

Beautiful…BGP routes :). Now if everything is configured correctly the connection should work.

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/73/116 ms

Indeed it does!
I hope you enjoyed it and as always you are welcome to comment on that!

Regards!
Markus

Posted in MPLS, Uncategorized | Tagged , , , , , , , , , , , , , , , , , , | 8 Comments

misc: new iphone 5 – new food from old dishes

Hi!
Just watched Apple´s new keynote and I dont know…in my eyes somehow Apple has lost its magic. I mean especially the new iPhone. In my eyes…absolutely nothing interesting new. Here is what they announced with the new phone.

The beginning
– In the beginning of the iPhone presentation the Apple presenter says “…it should be easy to send emails, write messages…” … “…thats the way how we designed it!”. Helloooo????? Thats nothing new, thats already what Apple did with the first iPhone.

New hi-speed mobile Internet
– Wooooow LTE..BIG NEW FEATURE…of course…because Apple missed the right time and now has to get into the race to compete Samsung and others. So LTE in my eyes is not a new invention like it is presented, but rather a technological update that is overdue. They already missed it with the iPad 3 in Germany where the Chip is not capable of the frequencies. Does apple dont test that?!?

New Display
– Ok the display is a retina display which already exists now since the iPhone 4. So only thing new is the upgrade to the bigger 4 inch screen and somehow the display shall be more truecolor like with more saturation. Also…nothing new except the social engineering method “bigger and with that its better”.

More Power
– Phone has a faster chip, faster graphics and so on. They promise 8h of phone calling with 3G enabled…guys…what about a business edition of the iPhone or so? you cannot go out of your home or drive in your car without a battery charger. Even if you are not doing anything. Why dont you enhance the power of the battery as you always do and enhance the uptime of such a phone, not the power?

Well all in all I think the presentation of the new iPhone wasn that cool as the presentations that have been made in the past. The presenter has a monotone voice and does not express that much enthusiasm.

All those critics are my own opinion.

Regards!
Markus

Posted in Misc | 4 Comments

installation and configuration of cisco secure acs 5.3 (vmware) – part 6

Hi again!
I got reminded that I obviously forgot to write part 6 of the Secure ACS implementation…well thats correct. Just forgot it :). But here it is!

So what we now have is two standalone Secure ACS 5.3. Each one has been isntalled the way you learned in the earlier parts. What we now are going to do is to attach the second machine to the primary machine, so that both of them do a full replication and build a cluster.
Cluster here means that a TACACS or RADIUS client can ask both machines equally…the primary or the secondary machine. Each machine will give the same answer.

First step here is that we can see the second machine with its state “primary”. This is usual because we haven´t done any cluster configuration yet.

On that machine (the second one) ee need to go to the “System Administration” menu to enter the “Deployment Operations” menu. There you enter the credentials (user/pass of the WebLogin, not the SSH/telnet login) and the ip address of the machine you want the secondary to be the backup from.

On the console you can also verify the “SECONDARY” state.

Then on the primary machine you can see that a new secondary has registered and is going top perform a replication. When replicating the database the backup machine is in the “PENDING” state.

Once the replication process is completet you should see the state “UPDATED”

The WebGui now shows also that our new machine has become the “SECONDARY”.

From now on every change we are doing on the “PRIMARY” machine is automatically replicated instantly to the “SECONDARY”.
So have fun with your redundant Secure ACS :).

Regards!
Feel free to comment!
Markus

Posted in Cisco Secure ACS 5.3 Installation & Configuration | Tagged , , , , , , , , , , , , , | 2 Comments

Thanks for over 25.000 views!

Just wanted to thank you for a lot of views in the last weeks and months. I hope you enjoy the reading. Also thanks for your constructive comments you are making! Keep going!

Regards! Markus

Posted in Misc | 1 Comment