时间的脚部虽然一秒一秒慢慢的滴答滴答，还是走到了2013年。
来到这里已经工作已经有一年两个月了，回想当初来这里应征时还想了蛮久的。
当初的想法，在这里工作几年就要回家了，现在还是没变。
今年2013 年有很多目标需要完成
- CISCO CCIE
- 减肥/训练 爬神山
- 努力存钱，买入想合股的公司股票
- 四叶草的幸福
- 学会说故事
Monday, December 31, 2012
Portfolio 2012 - Dec Q4
2/2/2011 - 虎年以1531.82点封关。
1/4/2011 Q1 KLSE 收在 1555点 +23.18
30/6/2011 Q2 KLSE 收在 1579 点 +24
30/9/2011 Q3 KLSE 收在 1387.13点 -192
1/4/2011 Q1 KLSE 收在 1555点 +23.18
30/6/2011 Q2 KLSE 收在 1579 点 +24
30/9/2011 Q3 KLSE 收在 1387.13点 -192
30/12/2011 Q4 KLSE 收在 1530.73点 +143.6
31/12/2012 Q4 KLSE 收在 1688.95点 + 158.22
31/12/2012 持有股票
CIMB 1023
FAJAR 7047
SUNREIT 5176
IGBREIT 5227
GENTING SP G13SUNWAY 5211
YTL 4677
TAMBUN 5191
PBB 4065
Total dividend 2012 = 651.75
Estimate dividend 2013 = 1000
接下来的2013年 要买入REIT股票
加码 YTL ,SUNWAY ,SUNREIT
买入 KLCCP,HAPSENG,BSTEAD,DIGI
Thursday, December 27, 2012
RIB, FIB, LFIB, LIB etc
It can be quite confusing to work out what all these terms are exactly referring to. I’ll try and put a concise answer for all of them here with an example.
RIB – Routing Information Base
This is the route table. i.e. When you do a show ip route, the RIB is what you see
This is the route table. i.e. When you do a show ip route, the RIB is what you see
AR1#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
10.0.0.0/32 is subnetted, 1 subnets
C 10.255.255.5 is directly connected, Loopback0
A router may have many separate RIB’s. If you’re running vrf’s with customer, then each vrf will have a separate RIB:
AR1#sh ip route vrf CUS1 | begin Gateway
Gateway of last resort is not set
C 192.168.1.0/24 is directly connected, FastEthernet0/0
AR1#sh ip route vrf CUS2 | begin Gateway
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, FastEthernet2/0
FIB – Forwarding Information Base
The FIB is an optimised version of the RIB. Or more correctly it’s the table a router looks at when deciding where to actually forward traffic. In Cisco land, the CEF table is a FIB.
The FIB is an optimised version of the RIB. Or more correctly it’s the table a router looks at when deciding where to actually forward traffic. In Cisco land, the CEF table is a FIB.
AR1#sh ip cef Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/8 drop 0.0.0.0/32 receive 10.255.255.5/32 receive 127.0.0.0/8 drop 224.0.0.0/4 drop 224.0.0.0/24 receive 240.0.0.0/4 drop 255.255.255.255/32 receive
Like the RIB, there can be multiple FIB tables on a router:
AR1#sh ip cef vrf CUS1 Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive 192.168.1.0/24 attached FastEthernet0/0 192.168.1.0/32 receive 192.168.1.1/32 receive 192.168.1.255/32 receive 224.0.0.0/24 receive 255.255.255.255/32 receive AR1#sh ip cef vrf CUS2 Prefix Next Hop Interface 0.0.0.0/0 drop Null0 (default route handler entry) 0.0.0.0/32 receive 172.16.1.0/24 attached FastEthernet2/0 172.16.1.0/32 receive 172.16.1.1/32 receive 172.16.1.255/32 receive 224.0.0.0/24 receive 255.255.255.255/32 receive
LIB – Label Information Base
The LIB is an MPLS table. This is the place where the router will keep all known MPLS labels. To take a look, you just need to use show mpls ldp bindings:
The LIB is an MPLS table. This is the place where the router will keep all known MPLS labels. To take a look, you just need to use show mpls ldp bindings:
AR1#sh mpls ldp bindings
tib entry: 10.0.0.0/30, rev 18
local binding: tag: 21
remote binding: tsr: 10.255.255.1:0, tag: imp-null
remote binding: tsr: 10.255.255.2:0, tag: imp-null
tib entry: 10.0.0.4/30, rev 16
local binding: tag: 20
remote binding: tsr: 10.255.255.1:0, tag: 32
remote binding: tsr: 10.255.255.2:0, tag: imp-null
tib entry: 10.0.0.8/30, rev 44
local binding: tag: 34
remote binding: tsr: 10.255.255.1:0, tag: 31
remote binding: tsr: 10.255.255.2:0, tag: 32
tib entry: 10.0.0.12/30, rev 42
local binding: tag: 33
remote binding: tsr: 10.255.255.1:0, tag: imp-null
remote binding: tsr: 10.255.255.2:0, tag: 31
tib entry: 10.1.0.0/30, rev 5
local binding: tag: imp-null
remote binding: tsr: 10.255.255.1:0, tag: imp-null
remote binding: tsr: 10.255.255.2:0, tag: 30
tib entry: 10.2.0.0/30, rev 4
local binding: tag: imp-null
remote binding: tsr: 10.255.255.1:0, tag: 30
remote binding: tsr: 10.255.255.2:0, tag: imp-null
tib entry: 10.7.0.0/30, rev 36
local binding: tag: 30
remote binding: tsr: 10.255.255.1:0, tag: 25
remote binding: tsr: 10.255.255.2:0, tag: 26
tib entry: 10.8.0.0/30, rev 34
local binding: tag: 29
remote binding: tsr: 10.255.255.1:0, tag: imp-null
remote binding: tsr: 10.255.255.2:0, tag: 25
tib entry: 10.255.255.1/32, rev 30
local binding: tag: 27
remote binding: tsr: 10.255.255.1:0, tag: imp-null
remote binding: tsr: 10.255.255.2:0, tag: 23
tib entry: 10.255.255.2/32, rev 10
local binding: tag: 17
remote binding: tsr: 10.255.255.1:0, tag: 23
remote binding: tsr: 10.255.255.2:0, tag: imp-null
tib entry: 10.255.255.3/32, rev 28
local binding: tag: 26
remote binding: tsr: 10.255.255.1:0, tag: 22
remote binding: tsr: 10.255.255.2:0, tag: 22
tib entry: 10.255.255.4/32, rev 26
local binding: tag: 25
remote binding: tsr: 10.255.255.1:0, tag: 21
remote binding: tsr: 10.255.255.2:0, tag: 21
tib entry: 10.255.255.5/32, rev 6
local binding: tag: imp-null
remote binding: tsr: 10.255.255.1:0, tag: 20
remote binding: tsr: 10.255.255.2:0, tag: 20
tib entry: 10.255.255.7/32, rev 24
local binding: tag: 24
remote binding: tsr: 10.255.255.1:0, tag: 18
remote binding: tsr: 10.255.255.2:0, tag: 18
AR1#
LFIB – Label Forwarding Instance Base
The LFIB is another MPLS table. This is the table that the router uses to forward labelled packets going through the network. Much like the RIB uses the FIB to forward traffic, so the LIB uses the LFIB to forward traffic. This is how you view it:
The LFIB is another MPLS table. This is the table that the router uses to forward labelled packets going through the network. Much like the RIB uses the FIB to forward traffic, so the LIB uses the LFIB to forward traffic. This is how you view it:
AR1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Pop tag 10.255.255.2/32 0 Se1/2 point2point
20 Pop tag 10.0.0.4/30 0 Se1/2 point2point
21 Pop tag 10.0.0.0/30 0 Se1/2 point2point
Pop tag 10.0.0.0/30 0 Se1/0 point2point
24 18 10.255.255.7/32 0 Se1/0 point2point
25 21 10.255.255.4/32 0 Se1/2 point2point
26 22 10.255.255.3/32 0 Se1/0 point2point
27 Pop tag 10.255.255.1/32 0 Se1/0 point2point
29 Pop tag 10.8.0.0/30 0 Se1/0 point2point
30 25 10.7.0.0/30 0 Se1/0 point2point
33 Pop tag 10.0.0.12/30 0 Se1/0 point2point
34 32 10.0.0.8/30 0 Se1/2 point2point
31 10.0.0.8/30 0 Se1/0
MPLS L3VPN – Route Distinguisher vs Route Target vs VPN label
A lot of people confuse the above 3 items. I’ll explain exactly what each of the 3 above items do, how you can see them, and how the routers use them to provide a L3VPN service.
Let’s take the following topology for this post:
Here we have 2 L3VPN customers running over our MPLS core. R5 is advertising 5.5.5.5/32. R8 is also advertising 5.5.5.5/32
Route Distinguisher:
The route distinguisher’s sole job is to keep a route unique while the PE routers advertise NLRI (Network Layer Reachability Information) to each other. If R5 and R8 both advertise 5.5.5.5/32 to R3, how will R3 advertise both of those routes to R4 while keeping them unique. The VPNV4 family itself doesn’t run in a VRF. It runs in the global routing instance and hence it needs something to distinguish a route.
Let’s take a quick look at the vrf RD config for both customers and then the vpnv4 route for 6.6.6.6/32 in the BGP table on R3:
R3#sh run | include ip vrf | rd
ip vrf CUS1
rd 3.3.3.3:100
ip vrf CUS2
rd 3.3.3.3:200
R3#sh bgp vpnv4 unicast rd 3.3.3.3:200 6.6.6.6
BGP routing table entry for 3.3.3.3:200:6.6.6.6/32, version 106
Paths: (1 available, best #1, table CUS2)
Not advertised to any peer
Local, imported path from 4.4.4.4:200:6.6.6.6/32
4.4.4.4 (metric 4) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 2, localpref 100, valid, internal, best
Extended Community: RT:100:200 OSPF DOMAIN ID:0x0005:0x000000030200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.47.4:0
mpls labels in/out nolabel/21
R3#sh bgp vpnv4 unicast rd 3.3.3.3:100 6.6.6.6
BGP routing table entry for 3.3.3.3:100:6.6.6.6/32, version 108
Paths: (1 available, best #1, table CUS1)
Not advertised to any peer
Local, imported path from 4.4.4.4:100:6.6.6.6/32
4.4.4.4 (metric 4) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 2, localpref 100, valid, internal, best
Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.46.4:0
mpls labels in/out nolabel/23
You can see that R3 has 2 vpnv4 routes for 6.6.6.6/32 – 3.3.3.3:200:6.6.6.6/32 and 3.3.3.3:100:6.6.6.6/32. They are unique as one contains :100: and the other contains :200: – Note that R4 does not have to match this RD in any way. It simple needs to be able to accept 2 unique routes. This is especially important when using route reflectors as RR’s will normally only advertise the best route to it’s clients. If they were not unique, the RR would only be advertising one of these routes. The RD in no way determines what VPN a route actually belongs to.
That’s all the route distinguisher does. No more.
Route Target:
The route target’s job is to tell the PE routers what VPN a route actually belongs to. Let’s take a look at the target config on R3:
R3#sh run | inc ip vrf|target ip vrf CUS1 route-target export 100:100 route-target import 100:100 ip vrf CUS2 route-target export 100:200 route-target import 100:200
When R3 receives an advertisement from R5, not only does it change the route into a vpnv4 route with the RD to make it unique, it also adds a community value to that advertisement. This is an RT value. Once this NLRI gets to R4, R4 will ensure that only routes that have a certain RT, will be placed in their respective VRF. As an example let’s have a look at the advertisements of 5.5.5.5 from R3 to R4:
R3#sh bgp vpnv4 unicast rd 3.3.3.3:100 5.5.5.5
BGP routing table entry for 3.3.3.3:100:5.5.5.5/32, version 37
Paths: (1 available, best #1, table CUS1)
Advertised to update-groups:
9
Local
10.0.35.5 from 0.0.0.0 (3.3.3.3)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.35.3:0
mpls labels in/out 24/nolabel
We can see the extended community of 100:100 is encoded into this NLRI on R3. This is advertised to R4:
R4#sh bgp vpnv4 unicast rd 3.3.3.3:100 5.5.5.5
BGP routing table entry for 3.3.3.3:100:5.5.5.5/32, version 178
Paths: (1 available, best #1, no table)
Not advertised to any peer
Local
3.3.3.3 (metric 4) from 3.3.3.3 (3.3.3.3)
Origin incomplete, metric 2, localpref 100, valid, internal, best
Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.35.3:0
mpls labels in/out nolabel/24
R4#sh run | include ip vrf | 100:100
ip vrf CUS1
route-target export 100:100
route-target import 100:100
R4 has an import 100:100 configuration under it’s VRF, and hence matching the community of 100:100 on the received NLRI, the PE router knows that the advertisement is meant for vrf CUS1. Note that the RD has nothing to do with this.
VPN Label:
The VPN label is to determine what VPN a packet belongs to. But hang on, surely that’s what the RT is for? No. The RT is for the control plane, while the VPN label is for the data plane. Let’s expand on that idea a bit. When R3 advertises NLRI to R4, the RT is used to determine where a route actually belongs. When it comes to R5 actually sending a packet to R6, the VPN label is used. Why? Because when a packet is sent, there is no field in the packet that the route-target is stored. Only the route advertisement contains the route-target as a community value. When R5 sends a ping to R6 from it’s loopback, it’s simply a packet with a destination address of 6.6.6.6 and a source address of 5.5.5.5.
So with L3VPNs we have two labels. The top label is the transport label and the bottom label is the VPN label. PHP will pop the transport label off the second to last router, but the VPN label will only be popped by the actual PE in question. When that frame comes in with the VPN label, R6 knows which VRF that packet belongs to.
VPN labels are advertised in the NLRI along with the RT. Let’s take a look at the 2 VPN labels that R4 is advertising to R3:
R3#sh bgp vpnv4 unicast rd 4.4.4.4:100 6.6.6.6
BGP routing table entry for 4.4.4.4:100:6.6.6.6/32, version 6
Paths: (1 available, best #1, no table)
Not advertised to any peer
Local
4.4.4.4 (metric 4) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 2, localpref 100, valid, internal, best
Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000000020200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.46.4:0
mpls labels in/out nolabel/21
R3#sh bgp vpnv4 unicast rd 4.4.4.4:200 6.6.6.6
BGP routing table entry for 4.4.4.4:200:6.6.6.6/32, version 8
Paths: (1 available, best #1, no table)
Not advertised to any peer
Local
4.4.4.4 (metric 4) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 2, localpref 100, valid, internal, best
Extended Community: RT:100:200 OSPF DOMAIN ID:0x0005:0x000000030200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.47.4:0
mpls labels in/out nolabel/23
We can see that R3 will use a VPN label of 21 when sending traffic to the CUS1 VRF, while it’ll use VPN label 23 when sending to CUS2′s VRF.
Let’s run a traceroute from R5 and R8 to confirm this.
CUS1:
CUS1:
R5#traceroute 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 1 10.0.35.3 36 msec * 52 msec 2 10.0.13.1 [MPLS: Labels 20/21 Exp 0] 120 msec 120 msec 132 msec 3 10.0.12.2 [MPLS: Labels 18/21 Exp 0] 92 msec 148 msec 104 msec 4 10.0.46.4 [MPLS: Label 21 Exp 0] 104 msec 100 msec 68 msec 5 10.0.46.6 172 msec * 140 msec
CUS2:
R8#traceroute 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 1 10.0.38.3 44 msec 64 msec 40 msec 2 10.0.13.1 [MPLS: Labels 20/23 Exp 0] 132 msec 132 msec 88 msec 3 10.0.12.2 [MPLS: Labels 18/23 Exp 0] 124 msec 156 msec 104 msec 4 10.0.47.4 [MPLS: Label 23 Exp 0] 192 msec 96 msec 76 msec 5 10.0.47.7 156 msec * 116 msec
The first hop for CUS1 shows a label stack of 20/21 – 20 being transport and 21 being the VPN. CUS2 uses 20/23 – Notice that as the egress PE is the same, the same transport label is used.
On the 3rd hop on both, R2 is popping off the transport label. Both frames now get to R4. One has a VPN label of 21 and the second a label of 23. R4 knows which VRF both packets belong to and sends them on their way to the correct routers.
Hopefully this helps clear this up for some of you..
Wednesday, December 26, 2012
MPLS Labs – VRFs and MP-BGP
So at this point, you might be thinking to yourself, “this is cool and all, but why do I need it”. Great question! MPLS was initially designed to be faster than normal IP switching. The idea was that a label lookup was faster than an IP lookup. These days, that’s no longer the case. We have 10 gig line rate interfaces that can do a lot of their functions in hardware. So what else can MPLS do? In my opinion, the biggest plus you get from MPLS is running it in conjunction with MP-BGP and VRFs. Rather than spend a lot of time explaining this, let’s just jump into the config so you can see how cool this is. Another look at our diagram…
Shows that we are looking at service provider network with two customers sharing the same provider infrastructure. That being said, let’s put the finishing touches on the PE routers to allow them to participate in MP-BGP.
PE1 router bgp 65000
no bgp default ipv4-unicast
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 7.7.7.7 activate
neighbor 3.3.3.3 activate
no bgp default ipv4-unicast
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 7.7.7.7 activate
neighbor 3.3.3.3 activate
PE2 router bgp 65000
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 7.7.7.7 activate
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 7.7.7.7 remote-as 65000
neighbor 7.7.7.7 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 7.7.7.7 activate
PE3 router bgp 65000
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 3.3.3.3 activate
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source l0
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source l0
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 3.3.3.3 activate
So this should look pretty familiar to anyone that’s worked with BGP minus a few of the commands. Let’s break those down…
no bgp default ipv4-unicast – Tells the router that for this BGP instance, we aren’t interested in normal IPv4 unicast routing. This being said, take a look at a ‘show ip bgp summary’. Nothing comes up however a look at ‘show ip protocol’ shows BGP running. It is running, we just aren’t looking at the right place now.
address-family vpnv4 – This command configures the BGP routing process for MP-BGP and the associate neighbor ‘activate’ commands activate each neighbor for VPNV4 routing.
So now you might be wondering, what is VPNV4. Before that comes up, we need to discuss a couple of other terms. VRFs,or Virtual Routing and Forwarding, allow you to make completely separate routing information based on a physical router. These are commonly used by service providers to keep different customer router segregated within their infrastructure. Along with VRFs come RDs, or route designators. Route designators get assigned to a VRF; so for now just think of a route designator as a way to identify a particular VRF. Also keep in mind that both of these items are locally significant to a router. The last item is a route target, or RT, and is considered to BGP to be an extended community string. The RT looks very similar to an RD but is what actually gets attached (exported) with the route when they are shared between MP-BP peers. So a VPNV4 route is a customers IPv4 router, with a RD attached to it. By adding the RD to the front of the route advertisement, we can make multiple advertisements for the same IPv4 network unique across common infrastructure. VRFs, RDs, and RTs are all ways to keep customer routes separate on shared infrastructure. Hopefully the rest of this config will clear things up for you.
PE1 ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100
PE1 ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100
router bgp 65000
address-family ipv4 vrf customer1
neighbor 192.168.10.2 remote-as 65100
neighbor 192.168.10.2 activate
neighbor 192.168.10.2 as-override
address-family ipv4 vrf customer1
neighbor 192.168.10.2 remote-as 65100
neighbor 192.168.10.2 activate
neighbor 192.168.10.2 as-override
int faste0/1
description Interface to CE1 – Customer1
ip vrf forwarding customer1
ip address 192.168.10.1 255.255.255.0
no shut
description Interface to CE1 – Customer1
ip vrf forwarding customer1
ip address 192.168.10.1 255.255.255.0
no shut
PE2 ip vrf customer2
rd 65200:200
route-target export 65200:200
route-target import 65200:200
rd 65200:200
route-target export 65200:200
route-target import 65200:200
router bgp 65000
address-family ipv4 vrf customer2
neighbor 192.168.20.2 remote-as 65200
neighbor 192.168.20.2 activate
neighbor 192.168.20.2 as-override
address-family ipv4 vrf customer2
neighbor 192.168.20.2 remote-as 65200
neighbor 192.168.20.2 activate
neighbor 192.168.20.2 as-override
int faste0/1
description Interface to CE2 – Customer2
ip vrf forwarding customer2
ip address 192.168.20.1 255.255.255.0
no shut
description Interface to CE2 – Customer2
ip vrf forwarding customer2
ip address 192.168.20.1 255.255.255.0
no shut
PE3 ip vrf customer1
rd 65100:100
route-target export 65100:100
route-target import 65100:100
rd 65100:100
route-target export 65100:100
route-target import 65100:100
ip vrf customer2
rd 65200:200
route-target export 65200:200
route-target import 65200:200
rd 65200:200
route-target export 65200:200
route-target import 65200:200
router bgp 65000
address-family ipv4 vrf customer1
neighbor 192.168.30.2 remote-as 65100
neighbor 192.168.30.2 activate
neighbor 192.168.30.2 as-override
address-family ipv4 vrf customer2
neighbor 192.168.40.2 remote-as 65200
neighbor 192.168.40.2 activate
neighbor 192.168.40.2 as-override
address-family ipv4 vrf customer1
neighbor 192.168.30.2 remote-as 65100
neighbor 192.168.30.2 activate
neighbor 192.168.30.2 as-override
address-family ipv4 vrf customer2
neighbor 192.168.40.2 remote-as 65200
neighbor 192.168.40.2 activate
neighbor 192.168.40.2 as-override
interface FastEthernet0/1.11
description Interface to CE3 – Customer1
encapsulation dot1Q 12
ip vrf forwarding customer1
ip address 192.168.30.1 255.255.255.0
description Interface to CE3 – Customer1
encapsulation dot1Q 12
ip vrf forwarding customer1
ip address 192.168.30.1 255.255.255.0
interface FastEthernet0/1.12
description Interface to CE4 – Customer2
encapsulation dot1Q 13
ip vrf forwarding customer2
ip address 192.168.40.1 255.255.255.0
description Interface to CE4 – Customer2
encapsulation dot1Q 13
ip vrf forwarding customer2
ip address 192.168.40.1 255.255.255.0
So let’s take a quick look at what we just did…
ip vrf customer1 – Creates a VRF called customer1
rd 65100:100 – Assings RD 65100:100 to that VRF
route-target export 65100:100 – Tells the router to export routes from this VRF with a RT of 65100:100
route-target import 65100:100 - Tells the router to import any VPNV4 routes that have a RT of 65100:100 into this VRF
rd 65100:100 – Assings RD 65100:100 to that VRF
route-target export 65100:100 – Tells the router to export routes from this VRF with a RT of 65100:100
route-target import 65100:100 - Tells the router to import any VPNV4 routes that have a RT of 65100:100 into this VRF
router bgp 65000
address-family ipv4 vrf customer1 – Create a routing instance for this VRF within BGP
neighbor 192.168.10.2 remote-as 65100 – Configure the peering to the customer (CE) router
neighbor 192.168.10.2 activate – Activate that router for VPNV4
neighbor 192.168.10.2 as-override – The customer is going to use the same AS number at all locations. I need to tell the BGP process to allow the same AS in multiple locations. Recall that if the BGP router sees it’s own AS in the AS-PATH of an incoming route, it will drop the route update as part of loop prevention.
address-family ipv4 vrf customer1 – Create a routing instance for this VRF within BGP
neighbor 192.168.10.2 remote-as 65100 – Configure the peering to the customer (CE) router
neighbor 192.168.10.2 activate – Activate that router for VPNV4
neighbor 192.168.10.2 as-override – The customer is going to use the same AS number at all locations. I need to tell the BGP process to allow the same AS in multiple locations. Recall that if the BGP router sees it’s own AS in the AS-PATH of an incoming route, it will drop the route update as part of loop prevention.
int faste0/1
description Interface to CE1 – Customer1
ip vrf forwarding customer1 – In this case we are assigning a physical interface to the customer1 VRF. NOTE – When you assign a interface to a VRF, it clears the interface IP so you’ll need to reassign it.
ip address 192.168.10.1 255.255.255.0 – Configure the IP address that the customer will be peering with
no shut
description Interface to CE1 – Customer1
ip vrf forwarding customer1 – In this case we are assigning a physical interface to the customer1 VRF. NOTE – When you assign a interface to a VRF, it clears the interface IP so you’ll need to reassign it.
ip address 192.168.10.1 255.255.255.0 – Configure the IP address that the customer will be peering with
no shut
The only thing left to do at this point is configure the customer CE routers. That config is pretty easy so let’s rip through that so we can dig into looking at how things are working.
CE1
hostname ce1
ip routing
ip cef
hostname ce1
ip routing
ip cef
no ip domain-lookup
line vty 0 15
password cisco
login
line vty 0 15
password cisco
login
int faste0/0
ip address 192.168.10.2 255.255.255.0
no shut
ip address 192.168.10.2 255.255.255.0
no shut
int faste0/1
ip address 10.10.10.1 255.255.255.0
no shut
ip address 10.10.10.1 255.255.255.0
no shut
router bgp 65100
neighbor 192.168.10.1 remote-as 65000
network 10.10.10.0 mask 255.255.255.0
neighbor 192.168.10.1 remote-as 65000
network 10.10.10.0 mask 255.255.255.0
CE2 hostname ce2
ip routing
ip cef
ip routing
ip cef
no ip domain-lookup
line vty 0 15
password cisco
login
line vty 0 15
password cisco
login
int faste0/0
ip address 192.168.20.2 255.255.255.0
no shut
ip address 192.168.20.2 255.255.255.0
no shut
int l99
ip address 172.16.1.1 255.255.255.0
no shut
ip address 172.16.1.1 255.255.255.0
no shut
ip route 172.16.1.0 255.255.255.0 null0
router bgp 65200
neighbor 192.168.20.1 remote-as 65000
neighbor 192.168.20.1 allowas-in
network 172.16.1.0 mask 255.255.255.0
neighbor 192.168.20.1 remote-as 65000
neighbor 192.168.20.1 allowas-in
network 172.16.1.0 mask 255.255.255.0
CE3 hostname ce3
ip routing
ip cef
ip routing
ip cef
no ip domain-lookup
line vty 0 15
password cisco
login
line vty 0 15
password cisco
login
int faste0/0
ip address 192.168.30.2 255.255.255.0
no shut
ip address 192.168.30.2 255.255.255.0
no shut
int l99
ip address 10.10.20.1 255.255.255.0
no shut
ip address 10.10.20.1 255.255.255.0
no shut
ip route 10.10.20.0 255.255.255.0 null0
router bgp 65100
neighbor 192.168.30.1 remote-as 65000
neighbor 192.168.30.1 allowas-in
network 10.10.20.0 mask 255.255.255.0
neighbor 192.168.30.1 remote-as 65000
neighbor 192.168.30.1 allowas-in
network 10.10.20.0 mask 255.255.255.0
CE4 hostname ce4
ip routing
ip cef
ip routing
ip cef
no ip domain-lookup
line vty 0 15
password cisco
login
line vty 0 15
password cisco
login
int faste0/0
ip address 192.168.40.2 255.255.255.0
no shut
ip address 192.168.40.2 255.255.255.0
no shut
int l99
ip address 172.16.2.1 255.255.255.0
no shut
ip address 172.16.2.1 255.255.255.0
no shut
ip route 172.16.2.0 255.255.255.0 null0
router bgp 65200
neighbor 192.168.40.1 remote-as 65000
neighbor 192.168.40.1 allowas-in
network 172.16.2.0 mask 255.255.255.0
neighbor 192.168.40.1 remote-as 65000
neighbor 192.168.40.1 allowas-in
network 172.16.2.0 mask 255.255.255.0
Soa s you can see, there’s nothing crazy about the CE config. Just basic IP and BGP configuration. We’ve defined a loopback 99 address as part of the larger class C network that we are advertising through BGP. Taking a look at the routing table of our CE router and we should see…
C 192.168.10.0/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
C 10.10.10.0 is directly connected, FastEthernet0/1
B 10.10.20.0 [20/0] via 192.168.10.1, 00:03:04
10.0.0.0/24 is subnetted, 2 subnets
C 10.10.10.0 is directly connected, FastEthernet0/1
B 10.10.20.0 [20/0] via 192.168.10.1, 00:03:04
Not only do we have our local routes, but we now have our route from our other customer router CE3. Cool huh? In addition, take a look at the routing table on a P router….
P1#show ip route
Codes: L – local, 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, l – LISP
+ – replicated route
Codes: L – local, 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, l – LISP
+ – replicated route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
5.0.0.0/32 is subnetted, 1 subnets
O 5.5.5.5 [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
6.0.0.0/32 is subnetted, 1 subnets
O 6.6.6.6 [110/3] via 172.172.172.22, 05:34:39, FastEthernet0/0.6
[110/3] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
7.0.0.0/32 is subnetted, 1 subnets
O 7.7.7.7 [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
172.172.0.0/16 is variably subnetted, 15 subnets, 2 masks
C 172.172.172.0/30 is directly connected, FastEthernet0/0.1
L 172.172.172.2/32 is directly connected, FastEthernet0/0.1
C 172.172.172.4/30 is directly connected, FastEthernet0/0.2
L 172.172.172.6/32 is directly connected, FastEthernet0/0.2
O 172.172.172.8/30
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
[110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
O 172.172.172.12/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
[110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
C 172.172.172.16/30 is directly connected, FastEthernet0/0.5
L 172.172.172.17/32 is directly connected, FastEthernet0/0.5
C 172.172.172.20/30 is directly connected, FastEthernet0/0.6
L 172.172.172.21/32 is directly connected, FastEthernet0/0.6
O 172.172.172.24/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O 172.172.172.28/30
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O 172.172.172.32/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
O 172.172.172.36/30
[110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
[110/3] via 172.172.172.18, 05:33:32, FastEthernet0/0.5
O 172.172.172.40/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
P1#
O 1.1.1.1 [110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
5.0.0.0/32 is subnetted, 1 subnets
O 5.5.5.5 [110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
6.0.0.0/32 is subnetted, 1 subnets
O 6.6.6.6 [110/3] via 172.172.172.22, 05:34:39, FastEthernet0/0.6
[110/3] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
7.0.0.0/32 is subnetted, 1 subnets
O 7.7.7.7 [110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
172.172.0.0/16 is variably subnetted, 15 subnets, 2 masks
C 172.172.172.0/30 is directly connected, FastEthernet0/0.1
L 172.172.172.2/32 is directly connected, FastEthernet0/0.1
C 172.172.172.4/30 is directly connected, FastEthernet0/0.2
L 172.172.172.6/32 is directly connected, FastEthernet0/0.2
O 172.172.172.8/30
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
[110/2] via 172.172.172.1, 05:34:02, FastEthernet0/0.1
O 172.172.172.12/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
[110/2] via 172.172.172.5, 05:33:52, FastEthernet0/0.2
C 172.172.172.16/30 is directly connected, FastEthernet0/0.5
L 172.172.172.17/32 is directly connected, FastEthernet0/0.5
C 172.172.172.20/30 is directly connected, FastEthernet0/0.6
L 172.172.172.21/32 is directly connected, FastEthernet0/0.6
O 172.172.172.24/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O 172.172.172.28/30
[110/2] via 172.172.172.18, 05:34:29, FastEthernet0/0.5
O 172.172.172.32/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
O 172.172.172.36/30
[110/3] via 172.172.172.22, 05:33:32, FastEthernet0/0.6
[110/3] via 172.172.172.18, 05:33:32, FastEthernet0/0.5
O 172.172.172.40/30
[110/2] via 172.172.172.22, 05:34:59, FastEthernet0/0.6
P1#
Notice anything weird? No customer routes! This post is getting a little long so I’m going to kill it here. In the next post, we’ll talk about how all of this works.
Subscribe to:
Posts (Atom)
