Lab6 Exercise IPv6 6PE Per POD

Juniper IPv6 lab exercise: 6PE
La b 6
IPv4 BGP Sessions Carrying IPv6 Routes – 6PE
Overview
In this lab, you will configure a full mesh of IPv4 iBGP sessions. You will then configure the PE
routers to carry IPv6 routes received from the CE routers over the iBGP IPv4 session (using MP-
BGP). Later on you will enable the forwarding of IPv6 traffic using MPLS.
You have been assigned a POD consisting of 4 devices: two PE routers and two CE routers. Make
sure you understand which devices have been assigned to you. This lab guide takes as a
configuration example POD A but this just a reference. Make sure you adapt your configurations to
your assigned POD, following always the lab diagram.
Note that your lab login (password lab123) grants you all permissions needed to complete this lab.
Please do not delete ge-0/0/0 interface since this is your management interface which grants you
connectivity to the devices. Please be careful, and have fun!
By completing this lab, you will perform the following tasks:
• Operational:
− Use show commands to verify and troubleshooting MP-BGP operation
• Configuration:
− Configure MP-BGP peering between loopback addresses
− Configure support for families inet and inet6
− Modify BGP next hop attribute
− Configure LSPs between your PE router and all other PE routers
− Configure MPLS and RSVP on your PE router
− Transport IPv6 traffic across your LSPs, and tagging of IPv6 traffic with the explicit
IPv6 null label on ingress.
Please refer to the next page lab diagram to perform this exercise and chose the one that refers to
your assigned POD.
1
Lab Diagram
Lab 6: 6PE IPv4 BGP Sessions Carrying IPv6 routes
10.10.x.y/24 = Serial Interfaces

192.168.x.y/32 = Loopback Interfaces
2001:10:0:a::b/64 = PE-CE Interfaces
2001:192:168:c::1/128 = Loopback Interfaces POD A
200.5x.y/24= Static Routes 2001:172:x:0-7/64 = Static Routes
MPLS LSP
2001:10:0:4::/64
10.10.1.0/24 10.10.8.0/24 2001:10:0:12::/64
CE-A1 :4::2 ge-0/0/1.0 Tokyo-PE
se-1/0/1 Sydney-P
Denver: ge-0/0/1.0 :4::1 lo0: se-1/0/1
lo0:
se-1/0/0 se-1/0/0 HongKong-PE :12::1 ge-0/0/1.0 CE-A2
::50::1 192.168.21.1 1.2 1.1 8.1 lo0: ge-0/0/1.0 :12::2 SaoPaulo
192.168.5.1 8.2 192.168.28.1 :51::1
AS 65000 eBGP 200.50.0.0/24 eBGP
200.50.1.0/24
200.51.0.0/24 AS 65000
2001:172:16:0::/64 200.50.2.0/24 MP-BGP 200.51.1.0/24
2001:172:16:4::/64
200.51.2.0/24
2001:172:16:1::/64 200.50.3.0/24
2001:172:16:2::/64
ISIS Level 2 200.51.3.0/24 2001:172:16:5::/64
2001:172:16:6::/64
2001:172:16:3::/64 AS 65412 2001:172:16:7::/64
Static Routes
Provider Core
(Virtual Customer Networks)
MPLS LSP
POD B
2001:10:0:6::/64 2001:10:0:14::/64
10.10.2.0/24 10.10.3.0/24
CE-B1 London-PE se-1/0/0
:6::2 se-2/0/0 Sydney-P se-2/0/1 se-1/0/0 Amsterdam-PE :14::1 ge-0/0/1.0 CE-B2
Madrid ge-0/0/1.0 :6::1 lo0: lo0: lo0:
:52::1 192.168.16.1
2.2 2.1 192.168.5.1 3.1 3.2 192.168.24.1 ge-0/0/1.0 :14::2 NewYork
:53::1
AS 65001 eBGP eBGP AS 65001

200.53.0.0/24
200.52.0.0/24
200.52.1.0/24
MP-BGP 200.53.1.0/24 2001:172:17:4::/64
2001:172:17:0::/64 200.53.2.0/24 2001:172:17:5::/64
2001:172:17:1::/64 200.52.2.0/24 ISIS Level 2 200.53.3.0/24 2001:172:17:6::/64
2001:172:17:2::/64
2001:172:17:3::/64
200.52.3.0/24
AS 65412 2001:172:17:7::/64
Static Routes
Provider Core
2
Lab 6: 6PE IPv4 BGP Sessions Carrying IPv6 routes
10.10.x.y/24 = Serial Interfaces

192.168.x.y/32 = Loopback Interfaces
2001:10:0:a::b/64 = PE-CE Interfaces
2001:192:168:c::1/128 = Loopback Interfaces POD C
200.5x.y/24= Static Routes 2001:172:x:0-7/64 = Static Routes
MPLS LSP
2001:10:0:8::/64 2001:10:0:16::/64
10.10.7.0/24 10.10.4.0/24
CE-C1 :8::2 ge-0/0/1.0 SanJosePE se-1/0/1 se-3/0/1 Sydney-P se-3/0/0 se-1/0/1 Montreal-PE :16::1 fe-0/0/1.0 CE-C2
Rome fe-0/0/1.0 :8::1 lo0: 7.2 7.1 lo0: lo0: ge-0/0/1.0 :16::2 Barcelona
:54::1 192.168.8.1 192.168.5.1
4.1 4.2 192.168.12.1 :55::1
AS 65002 eBGP eBGP AS 65002

200.54.0.0/24 MP-BGP 200.55.0.0/24
2001:172:18:0::/64 200.54.1.0/24 200.55.1.0/24 2001:172:18:4::/64
2001:172:18:1::/64 200.54.2.0/24 ISIS Level 2 200.55.2.0/24 2001:172:18:5::/64
2001:172:18:2::/64
2001:172:18:3::/64
200.54.3.0/24
AS 65412 200.55.3.0/24 2001:172:18:6::/64
2001:172:18:7::/64
Static Routes
Provider Core
3
Key Commands
Key operational mode commands used in this lab include the following:
show bgp summary
show bgp neighbor
show route
show route table inet6
show route table inet.3
show route table inet6.3
show route advertising-protocol bgp
show route receive-protocol bgp
show route hidden extensive
show rsvp session
ping
traceroute
Part 1: Restore IPv6 bgp native configuration

Step 1.1
Familiarize yourself with the 6PE topology described in the lab 6 diagram handout. You will configure
a pair of PE and CE routers.
Log into your PE and CE routers and go ahead and load the lab6-6pe-start file that is located in
the ipv6/ directory of your device. This will give us a working baseline configuration on the devices.
lab@Tokyo-PE> configure
Entering configuration mode
[edit]
lab@London-PE# load override ipv6/lab6-6pe-start
load complete
Familiarize with the configuration just loaded. You will notice that there are inet and inet6 families
configured on the interfaces with respective IPv4 and IPv6 addresses. There is also an operational
IGP that guarantees reachability to all internal networks within the Provider Autonomous System AS
65412. On top of that, there is an ipv4 iBGP full mesh of sessions, an ipv6 eBGP session with your
peering AS and also some static routes on the CE devices
Once you are satisfied commit your configuration.
[edit]
lab@Tokyo-PE# commit and-quit
commit complete
Now login into your CE assigned device and load the ipv6/lab6-6pe-start file. This will give us
back a working baseline configuration.
lab@Denver-CE_A1> configure
[edit]
lab@Denver-CE_A1# load override ipv6/lab6-6pe-start
load complete
4
Familiarize with the configuration just loaded. Like in the PE case, you will notice that there are inet
and inet6 families configured on the interfaces with respective IPv4 and IPv6 addresses. There are
also some IPv4 & IPv6 static routes in there and an eBGP peering session with AS65412
Once you are satisfied with your inspection go ahead and commit your configuration.
[edit]
lab@Denver-CE_A1# commit and-quit
commit complete
Step 1.2
On your PE device, remove your iBGP sessions using IPv6 so you no longer use Native IPv6 BGP.
To do so, get rid of the protocols bgp group ibgp section of your configuration:
[edit]
lab@Tokyo-PE# delete protocols bgp group ibgp
Please ensure that your ebgp group to your CE neighboring router remains configured.
Part 2: Configure iBGP over IPv4

Step 2.1
Create a new full mesh IBGP topology between your PE router and all other PE routers that belong
to your POD using IPv4. Use the loopback interfaces. Your PE router will be still part of autonomous
system number 65412 so no changes there.
Please refer to the lab diagram and the following table which provides the loopback addresses of all
routers as a reference:
Router Loopback address

Tokyo 192.168.21.1
Hong Kong 192.168.28.1
London 192.168.16.1
Amsterdam 192.168.24.1
San Jose 192.168.8.1
Montreal 192.168.12.1
Create a new bgp group called v4-peers on your PE device and configure a full mesh of IPv4
sessions with all other PEs assigned to your POD. In this case, since you have been given only 2x
5
PE routers, you will have to configure just one session to your other PE.. The following example has
been taken from the Tokyo router:
[edit]
lab@Tokyo-PE# edit protocols bgp group v4-peers
[edit protocols bgp group v4-peers]
lab@Tokyo-PE# set type internal
lab@Tokyo-PE# set local-address 192.168.21.1
lab@Tokyo-PE# set neighbor 192.168.28.1
Your configuration should look like the following output taken from Tokyo:

lab@Tokyo-PE# show
type internal;
local-address 192.168.21.1;
neighbor 192.168.28.1;
Go ahead and commit your changes:

lab@Tokyo-PE# commit
commit complete
Step 2.2
Verify that all your IBGP sessions have been established.

lab@Tokyo-PE# run show bgp summary
Groups: 2 Peers: 6 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet6.0 5 5 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Damped...
192.168.28.1 65412 3 3 0 0 6
0/0/0/0 0/0/0/0
2001:10:0:4::2 65000 5 5 0 0 44
Establ
inet6.0: 5/5/5/0
6
♦ Are all of your BGP session established?
Yes they are.
♦ Check the neighbor details for your IBGP session. Which route family can your IBGP
sessions carry at this point?
The NLRI that has been negotiated is inet (IPv4) unicast, which is the address family
being used to establish the session.

lab@Tokyo-PE# run show bgp neighbor
Peer: 192.168.28.1+64689 AS 65412 Local: 192.168.21.1+179 AS 65412
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress Refresh>
Local Address: 192.168.21.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.28.1 Local ID: 192.168.21.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 65412)
Peer does not support Addpath
Table inet.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 0
7
Last traffic (seconds): Received 3 Sent 6 Checked 51

Input messages: Total 8 Updates 1 Refreshes 0 Octets 196
Output messages: Total 8 Updates 0 Refreshes 0 Octets 215
Output Queue[1]: 0
...
Step 2.3
Configure the IPv4 static routes shown on the IPv4 addressing lab diagram, on your PE router. A
reject next hop is suggested because the resulting ICMP destination unreachable error messages
help to validate connectivity to the prefixes encompassed by the static route.
Please refer to the following table and diagram to configure your static routes on each router:
Tokyo HongKong London Amsterdam SanJose Montreal

200.50.0.0/24 200.51.0.0/24 200.52.0.0/24 200.53.0.0/24 200.54.0.0/24 200.55.0.0/24
200.50.1.0/24 200.51.1.0/24 200.52.1.0/24 200.53.1.0/24 200.54.1.0/24 200.55.1.0/24
200.50.2.0/24 200.51.2.0/24 200.52.2.0/24 200.53.2.0/24 200.54.2.0/24 200.55.2.0/24
200.50.3.0/24 200.51.3.0/24 200.52.3.0/24 200.53.3.0/24 200.54.3.0/24 200.55.3.0/24
Issue the following commands for your static routes configuration:

lab@Tokyo-PE# top edit routing-options
[edit routing-options]
lab@Tokyo-PE# set static route 200.50.0/24 reject
Display your static routes for confirmation:
lab@Tokyo-PE# show
static {
route 200.50.0.0/24 reject;
}
autonomous-system 65412;
8
Step 2.4
Configure a policy to advertise these statics routes via IBGP.
lab@Tokyo-PE# top
[edit]
lab@Tokyo-PE# edit policy-options policy-statement send-statics-v4
[edit policy-options policy-statement send-statics-v4]
lab@Tokyo-PE# set term 1 from protocol static
lab@Tokyo-PE# set term 1 then accept
Display your policy for confirmation:

lab@Tokyo-PE# show
term 1 {
from protocol static;
then accept;
}
Apply the newly created send-statics-v4 policy into your bgp group v4-peers. Also, apply the
next-hop self policy NH that you created on the previous lab. Ensure that the two policies are applied
under your v4-peers group:

lab@Tokyo-PE# top
[edit]
lab@Tokyo-PE# set protocols bgp group v4-peers export send-statics-v4
[edit]
lab@Tokyo-PE# set protocols bgp group v4-peers export NH
Your configuration should look like the following output taken from Tokyo:
[edit]
lab@Tokyo-PE# show protocols bgp
group ebgp {
type external;
peer-as 65000;
as-override;
neighbor 2001:10:0:4::2;
}
group v4-peers {
type internal;
9
export [ send-statics-v4 NH ];
neighbor 192.168.28.1;
}
Once satisfied with your changes go ahead and commit your candidate configuration:
[edit]
commit complete
Step 2.5
Once completed these last two steps you should have all the 200.x.y/24 routes in your routing table.
♦ Do you have all the 200.x.y/24 routes in your routing table? If so, how many?
Every router should have 8 x 200.x.y/24 routes in its inet.0 table
[edit]
lab@Tokyo-PE# run show route 200/8 terse | match /24 | count
Count: 24 lines
[edit]
lab@Tokyo-PE# run show route 200/8 terse
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)+ = Active
Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 200.50.0.0/24 S 5 Reject
* 200.50.1.0/24 S 5 Reject
* 200.50.2.0/24 S 5 Reject
* 200.50.3.0/24 S 5 Reject
* 200.51.0.0/24 B 170 100 >10.10.1.1 I
* 200.51.1.0/24 B 170 100 >10.10.1.1 I
* 200.51.2.0/24 B 170 100 >10.10.1.1 I
* 200.51.3.0/24 B 170 100 >10.10.1.1 I
10
Part 3: Configure the Advertisement of IPv6 Routes over your IBGP-IPv4

Session
Step 3.1
Configure your PE router to carry IPv6 NLRI across the IBGP over IPv4 session. After you have
added the required command, check the IBGP neighbor status and details again. Also check your
IPv4 routing table again.
As the family inet6 unicast is added under the IBGP group, your sessions will gradually get
reestablished.
[edit]
lab@Tokyo-PE# set family inet6 unicast
Your configuration should look like this example taken from Tokyo-PE. Commit your configuration.

lab@Tokyo-PE# show
type internal;
family inet6 {
unicast;
}
neighbor 192.168.28.1;

commit complete
Step 3.2
Display the status of the bgp sessions. Notice that they now show the inet6.0 routing table as the
routing table were routes are to be installed.

inet6.0
10 5 0 0 0 0
inet.0
0 0 0 0 0 0
11

State|#Active/Received/Accepted/Damped...
192.168.28.1 65412 4 5 0 0 51
Establ
inet6.0: 0/5/5/0
2001:10:0:4::2 65000 35 36 0 0 14:31
Establ
inet6.0: 5/5/5/0
♦ Is the inet-unicast family still enabled for the session?
If you now try the show BGP neighbor command and look for the address families and
NLRI negotiated you find that only inet6-unicast is active. This may cause confusion
since in Step 2.2 we confirmed that IPv4-unicast was enabled automatically based on
the use of IPv4 address to establish the peers. The problem arises from the manual
configuration of family inet6-unicast. The router is now expecting all address families
to be supported on each IBGP session to also be manually configured.

lab@Tokyo-PE# run show bgp neighbor
Peer: 192.168.28.1+179 AS 65412 Local: 192.168.21.1+60083 AS 65412
Last Error: None
Export: [ send-statics-v4 NH ]
Options: <Preference LocalAddress AddressFamily Refresh>
Address families configured: inet6-unicast
Number of flaps: 0
BFD: disabled, down
NLRI for restart configured on peer: inet6-unicast
NLRI advertised by peer: inet6-unicast
NLRI for this session: inet6-unicast
Stale routes from peer are kept for: 300
...
♦ Are you still receiving IPv4 routes from other PE routers?
The same command we used on Step 2.5 reports that only 4x 200.x.y/24 routes are
12
now on the routing table. An inspection of the actual routes shows us that the four
routes currently in the routing table are the local static routes.

lab@Tokyo-PE# run show route 200/8 terse | match /24 | count
Count: 4 lines

lab@Tokyo-PE# run show route 200/8 terse
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
* 200.50.0.0/24 S 5 Reject
* 200.50.1.0/24 S 5 Reject
* 200.50.2.0/24 S 5 Reject
* 200.50.3.0/24 S 5 Reject
Step 3.3
Reconfigure your PE router to carry IPv4 NLRI across the IBGP sessions again. To solve the
problem all is needed is the addition of family inet unicast under the IBGP group v4-peers:

lab@Tokyo-PE# set family inet unicast
Your configuration should look like this example taken from Tokyo-PE. Commit your configuration.

lab@Tokyo-PE# show
type internal;
family inet {
unicast;
}
family inet6 {
unicast;
}
neighbor 192.168.28.1;

commit complete
After this change check the IBGP neighbor details as well as your routing table.
13
♦ Does your session now carry both inet unicast and inet6 unicast NLRI?
It is easy to see that now you can now exchange both IPv4 and IPv6 routes with your
neighbors just by looking at the output of the show bgp summary command:

inet6.0
10 5 0 0 0 0
inet.0
4 4 0 0 0 0
State|#Active/Received/Accepted/Damped...
192.168.28.1 65412 13 12 0 0 3:37
Establ
inet6.0: 0/5/5/0
inet.0: 4/4/4/0
2001:10:0:4::2 65000 54 54 0 0 23:03
Establ
inet6.0: 5/5/5/0
♦ Do you have both IPv4 and IPv6 BGP routes in your routing table?
You should be seeing IPv4 routes to the remote PE router’s static routes. You should
also be seeing IPv6 routes to your CE router’s static routes. You can see that the router
in the example is receiving and activating 4x IPv4 routes from each of its peers. The
router is also receiving and activating 5 routes from the CE router (2001:10:0:4::2 ).
♦ Are you advertising any IPv6 routes to your IBGP peers?
Remember that previously you added the next-hop self policy to your IBGP group. You
can use the show route advertising-protocol command to determine
whether you are sending routes. The following example shows you that effectively the
14
router is sending both IPv4 and IPv6 routes and in both cases, the next-hop for the
routes is self which should make all routes valid in the receiving router.

lab@Tokyo-PE# run show route advertising-protocol bgp 192.168.28.1
Prefix Nexthop MED Lclpref AS path
* 200.50.0.0/24 Self 100 I
* 200.50.1.0/24 Self 100 I
* 200.50.2.0/24 Self 100 I
* 200.50.3.0/24 Self 100 I
inet6.0: 49 destinations, 50 routes (24 active, 0 holddown, 25 hidden)
Prefix Nexthop MED Lclpref AS path
* 2001:172:16::/64 Self 100 65000 I
* 2001:172:16:1::/64 Self 100 65000 I
* 2001:172:16:2::/64 Self 100 65000 I
* 2001:172:16:3::/64 Self 100 65000 I
2001:192:168:50::/64
* Self 100 65000 I
♦ Are you receiving any IPv6 routes from your IBGP peers?
By the looks you are not receiving any IPv6 route from your PE neighbors. However,
do notice that you have quite a few hidden routes. By entering the show route hidden
table inet6 you can check if you have hidden routes.

lab@Tokyo-PE# run show route receive-protocol bgp 192.168.28.1 table inet6

lab@Tokyo-PE# run show route hidden
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
2001:172:16:4::/64 [BGP/170] 00:07:11, localpref 100, from 192.168.28.1
AS path: 65000 I
Unusable
AS path: 65000 I
15
Unusable
AS path: 65000 I
Unusable
AS path: 65000 I
Unusable
2001:192:168:51::/64
[BGP/170] 00:07:11, localpref 100, from 192.168.28.1
AS path: 65000 I
Unusable
If you use the extensive switch and check the details for one of your hidden routes you will discover
the reason it is hidden

lab@Tokyo-PE# run show route hidden extensive 2001:172:16:4::/64
2001:172:16:4::/64 (1 entry, 0 announced)
BGP Preference: 170/-101
Next hop type: Unusable
Next-hop reference count: 5
State: <Hidden Int Ext>
Local AS: 65412 Peer AS: 65412
Age: 2:52:58
Task: BGP_65412.192.168.28.1+179
AS path: 65000 I
Localpref: 100
Router ID: 192.168.28.1
Indirect next hops: 1
Protocol next hop: ::ffff:192.168.28.1
Indirect next hop: 0 -
♦ What is the BGP next-hop of those hidden IPv6 routes?
In the case of the route 2001:172:16:4::/64 the BGP next-hop happens to be

::ffff:192.168.28.1. You can try to find a route to the next hop in your routing
table

lab@Tokyo-PE# run show route ::ffff:192.168.28.1
No route was found! Therefore, next-hop reachability fails, and the route becomes unusable and
hidden.
16
____________________________ Note__________________________
The next-hop ::ffff:192.168.28.1 in the example, is the IPv4-mapped
representation of the IPv4 address of HongKong’s loopback interface. The next
hop is automatically converted by the router when an IPv6 route is transported
over an IPv4 session. The problem is the router has no route in inet6 to resolve
this next hop.
__________________________________________________________________
___________________________ Note 2 !! ________________________

An IPv4-mapped address has its first 80 bits set to zero and the next 16 set to
one, while its last 32 bits are filled with the IPv4 address. These addresses are
commonly represented in the standard IPv6 format, but having the last 32 bits
written in the customary dot-decimal notation of IPv4; for example,
::ffff:192168.28.1 represents the IPv4 address 192.168.28.1
__________________________________________________________________
Part 4: Repair unusable routes

Step 4.1
How do we make disappear the 5 unusable routes that we still have on the hidden table?
In order to fix this reachability problem, you will simply add the ::ffff:192.168.x.1 address as a
secondary loopback IPv6 address in your PE router.That new address will be automatically
advertised by ISIS and resolve the next-hop reachability problems.
Configure the following IPv6 address on your lo0.0 interface.
Router New IPv6 address for lo0.0

Tokyo ::ffff:192.168.21.1
Hong Kong ::ffff:192.168.28.1
London ::ffff:192.168.16.1
Amsterdam ::ffff:192.168.24.1
San Jose ::ffff:192.168.8.1
Montreal ::ffff:192.168.12.1
[edit policy-options policy-statement NH]

lab@Tokyo-PE# top edit interfaces lo0
[edit interfaces lo0]
lab@Tokyo-PE# set unit 0 family inet6 address ::ffff:192.168.21.1
17
Your configuration should look like this output taken from the Tokyo router. Go ahead and commit
your changes.

lab@Tokyo-PE# show
unit 0 {
family inet {
address 192.168.21.1/32;
}
family iso {
address 49.0001.1111.2222.1111.00;
}
family inet6 {
address 2001:192:168:21::1/128;
address ::ffff:192.168.21.1/128;
}
}
commit complete
Exiting configuration mode
♦ Is your router advertising its ::ffff:192.168.x.1 address on the IGP ?
Yes, the new loopback address is now advertised on your ISIS LSP
lab@Tokyo-PE> show isis database Tokyo detail

IS-IS level 1 link-state database:
IS-IS level 2 link-state database:
Tokyo-PE.00-00 Sequence: 0x1f1, Checksum: 0x9d8f, Lifetime: 828 secs
IS neighbor: Sydney-P.00 Metric: 10
IP prefix: 10.10.1.0/24 Metric: 10 Internal Up
IP prefix: 192.168.21.1/32 Metric: 0 Internal Up
V6 prefix: ::ffff:192.168.21.1/128 Metric: 0 Internal Up
V6 prefix: 2001:10:0:30::/64 Metric: 10 Internal Up
V6 prefix: 2001:192:168:21::1/128 Metric: 0 Internal Up
♦ Once all PE routers have done the above changes, do you still see hidden routes in
your router?
18
No, hidden routes are gone now ☺
lab@Tokyo-PE> show route hidden

♦ Do you have IPv4 BGP routes to all the static routes from all PE routers across the
network?
Yes. There should be 8x 200.#.#/24 routes in inet.0.
lab@Tokyo-PE> show route 200/8 terse | match /24 | count

Count: 8 lines
lab@Tokyo-PE> show route 200/8 terse

* 200.50.0.0/24 S 5 Reject
* 200.50.1.0/24 S 5 Reject
* 200.50.2.0/24 S 5 Reject
* 200.50.3.0/24 S 5 Reject
* 200.51.0.0/24 B 170 100 >10.10.1.1 I
* 200.51.1.0/24 B 170 100 >10.10.1.1 I
* 200.51.2.0/24 B 170 100 >10.10.1.1 I
* 200.51.3.0/24 B 170 100 >10.10.1.1 I
♦ Do you have IPv6 BGP routes to all the static routes from all CE routers across the
network?
Yes. There should be 8x 2001:172.#.#/64 routes in inet6.0.
19
lab@Tokyo-PE> show route 2001:172::/32 terse | match /64 | count

Count: 8 lines
lab@Tokyo-PE> show route 2001:172::/32 terse

* 2001:172:16::/64 B 170 100 >2001:10:0:4::2 65000 I
* 2001:172:16:1::/64 B 170 100 >2001:10:0:4::2 65000 I
* 2001:172:16:2::/64 B 170 100 >2001:10:0:4::2 65000 I
* 2001:172:16:3::/64 B 170 100 >2001:10:0:4::2 65000 I
* 2001:172:16:4::/64 B 170 100 >fe80::205:86ff:fe71:5000 65000 I
* 2001:172:16:5::/64 B 170 100 >fe80::205:86ff:fe71:5000 65000 I
* 2001:172:16:6::/64 B 170 100 >fe80::205:86ff:fe71:5000 65000 I
* 2001:172:16:7::/64 B 170 100 >fe80::205:86ff:fe71:5000 65000 I
At last, Verify the advertisement of routes from your CE router to other CE routers.
♦ Is your CE router receiving all IPv6 routes from the other CEs?
Yes. There should be 8x 2001:172.#.#/64 routes in its inet6.0 table.The following

example shows that Denver_CE-A1 is receiving all the expected routes from the other
CE routers.
lab@Denver-CE_A1> show route table inet6 terse 2001:172::/32 | match /64 | count
Count: 8 lines
lab@Denver-CE_A1> show route table inet6 terse 2001:172::/32

* 2001:172:16::/64 S 5 Reject
* 2001:172:16:1::/64 S 5 Reject
* 2001:172:16:2::/64 S 5 Reject
* 2001:172:16:3::/64 S 5 Reject
* 2001:172:16:4::/64 B 170 100 >2001:10:0:4::1 65412 65412 I
* 2001:172:16:5::/64 B 170 100 >2001:10:0:4::1 65412 65412 I
* 2001:172:16:6::/64 B 170 100 >2001:10:0:4::1 65412 65412 I
* 2001:172:16:7::/64 B 170 100 >2001:10:0:4::1 65412 65412 I
20
♦ Looking good, right?? As a definitive test, can your CE router reach all IPv6 routes
from the other CEs? Can you ping for example the IPv6 address of the remote CE?
No you can’t!! There seem to be a forwarding problem in the Provider core network.
The destination route from the remote CE (i.e. the loopback) is present on the routing
table, however forwarding doesn’t seem to work
lab@Denver-CE_A1> ping 2001:192:168:51::1 source 2001:192:168:50::1

PING6(56=40+8+8 bytes) 2001:192:168:50::1 --> 2001:192:168:51::1
^C
--- 2001:192:168:51::1 ping6 statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
lab@Denver-CE_A1> show route 2001:192:168:51::1

2001:192:168:51::/64
*[BGP/170] 00:08:00, localpref 100
AS path: 65412 65412 I
> to 2001:10:0:4::1 via ge-0/0/1.0
Part 5: Configure MPLS and RSVP

Step 5.1
Enable MPLS and RSVP at the protocols level on your PE router’s interface se-1/0/x.0. Remember
to add family mpls under the interface as well.
Go ahead and add support for the family mpls in your serial interface. This enables the processing of
labels in and out of the interface:
[edit]
lab@Tokyo-PE# set interfaces se-1/0/1 unit 0 family mpls
Now you will configure the mpls switching protocol:
[edit]
lab@Tokyo-PE# set protocols mpls interface se-1/0/1
21
And at last you also need to enable RSVP, but only at the protocol level. Commit your changes
[edit]
lab@Tokyo-PE# set protocols rsvp interface se-1/0/1
[edit]
commit complete
Step 5.2
Verify your interface is running both RSVP and MPLS. You can use the commands shown in the
example below to verify proper MPLS and RSVP configuration.
[edit]
lab@Tokyo-PE# run show mpls interface
Interface State Administrative groups
se-1/0/1.0 Up <none>
[edit]
lab@Tokyo-PE# run show rsvp interface
RSVP interface: 1 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
se-1/0/1.0 Up 0 100% 8Mbps 8Mbps 0bps 0bps
Step 5.3
Create LSPs from your PE router to your other PE router in the network. You will have a total of one
LSPs. The loopback addresses of all PE routers are listed below. Use these addresses as the
egress for your LSPs.
Router Loopback address

Tokyo 192.168.21.1
Hong Kong 192.168.28.1
London 192.168.16.1
Amsterdam 192.168.24.1
San Jose 192.168.8.1
Montreal 192.168.12.1
22
To create an LSP you need to define a name for it under protocols MPLS and specify the address of
the egress of the router.
The following example shows the LSPs created in Tokyo:
[edit]
lab@Tokyo-PE# edit protocols mpls
[edit protocols mpls]
lab@Tokyo-PE# set label-switched-path TKY-to-HKG to 192.168.28.1
Your configuration should look like this. Commit your changes when satisfied:

lab@Tokyo-PE# show
label-switched-path TKY-to-HKG {
to 192.168.28.1;
}
interface se-1/0/1.0;

commit complete
Step 5.4
Verify that your LSPs have been established.
♦ Are your RSVP LSPs established?
Yes. You should have one LSP as ingress and one LSPs as egress established.

lab@Tokyo-PE# run show rsvp session
Ingress RSVP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.28.1 192.168.21.1 Up 0 1 FF - 300880 TKY-to-HKG
Total 1 displayed, Up 1, Down 0
Egress RSVP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
23
192.168.21.1 192.168.28.1 Up 0 1 FF 3 - HKG-to-TKY

Transit RSVP: 0 sessions
♦ Do you have the egress loopback addresses to your LSPs in inet.3?
Yes, as expected the loopback addresses of the terminating point of your LSP have
been installed into inet.3. RSVP, which is the protocol used in the lab to signal your
LSPs, installs routes to the egress router’s address in inet.3.

lab@Tokyo-PE# run show route table inet.3
192.168.28.1/32 *[RSVP/7/1] 00:02:41, metric 20
> via se-1/0/1.0, label-switched-path TKY-to-HKG
♦ Now look at your inet.0 routing table. What is the next hop of the IPv4 routes you
are receiving from other iBGP peers? Is this next-hop being resolved through inet.3? is
the route bounded to the LSP?
You will find that after creating your LSP the next hop for the static routes on the other
PE routers is now the LSP to the corresponding PE router. This is the result of BGP
resolving the BGP next hop for the route which is the loopback address of the other PE
router

lab@Tokyo-PE# run show route 200.51.0/24
200.51.0.0/24 *[BGP/170] 22:57:49, localpref 100, from 192.168.28.1
AS path: I
When BGP performs next-hop resolution it can look at both inet.0 and inet.3 and choose the route
with the lowest preference, in this case the RSVP route in inet.3.
24

lab@Tokyo-PE# run show route 192.168.28.1
192.168.28.1/32 *[IS-IS/18] 00:49:55, metric 20
> to 10.10.1.1 via se-1/0/1.0

192.168.28.1/32 *[RSVP/7/1] 00:04:49, metric 20
____________________________ Note__________________________
When the routing process tries to determine the best forwarding path to the BGP
next hop (which is also the LSP’s egress address in this example), it has the
option to resolve the BGP next hop through the inet.0 or the inet.3 routing tables.
Because the global preference for the entries in inet.3 is less than the preference
for the same route in inet.0 table, the BGP entity prefers the entries found in
inet.3. The result is that the LSP is installed into the forwarding table as the next
hop for all routes whose BGP next hop resolves to the egress address
associated with the LSP.
__________________________________________________________________
After next-hop resolution is completed, BGP installs a BGP route in inet.0 using the LSP as the next
hop. You can observe the process in the following example:

lab@Tokyo-PE# run show route 200.51.0/24 extensive
200.51.0.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 200.51.0.0/24 -> {indirect(262142)}
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x9269690
Source: 192.168.28.1
Next hop type: Router, Next hop index: 579
Next hop: via se-1/0/1.0 weight 0x1, selected
Label-switched-path TKY-to-HKG
Label operation: Push 300880
Label TTL action: prop-ttl
Protocol next hop: 192.168.28.1
Indirect next hop: 90d80e8 262142
State: <Active Int Ext>
25
Age: 31:10 Metric2: 20

Task: BGP_65412.192.168.28.1+179
Announcement bits (2): 0-KRT 4-Resolve tree 4
AS path: I
Accepted
Localpref: 100
Router ID: 192.168.28.1
Protocol next hop: 192.168.28.1 Metric: 20
Indirect next hop: 90d80e8 262142
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: via se-1/0/1.0 weight 0x1
192.168.28.1/32 Originating RIB: inet.3
Metric: 20 Node path count: 1
Forwarding nexthops: 1
Nexthop: via se-1/0/1.0
As a result, traffic destined to 200.51.0.0/24 will use the TKY-to-HKG LSP. You could test that by
conducting a traceroute to any of the ip addresses you are receiving via BGP from other PE peers:
lab@Tokyo-PE# run traceroute 200.51.0.2

traceroute to 200.51.0.2 (200.51.0.2), 30 hops max, 40 byte packets
1 10.10.1.1 (10.10.1.1) 115.859 ms 120.127 ms 96.804 ms
MPLS Label=300880 CoS=0 TTL=1 S=1
2 10.10.8.2 (10.10.8.2) 12.769 ms !N 9.550 ms !N 10.593 ms !N
Step 5.5
♦ Can the router forward IPv6 across your LSPs the same way? Why or why not?
(Check the routing table for routes to the static IPv6 routes of remote CE routers.)
If you check the routing table for IPv6 routes coming from a remote peer, you will find
that these routes do not use the LSP as a next hop like the IPv4 routes. Just pick one
IPv6 route being received from another PE

lab@Tokyo-PE# run show route 2001:172:16:4::/64
inet6.0: 28 destinations, 29 routes (28 active, 0 holddown, 0 hidden)+ = Active
Route, - = Last Active, * = Both
2001:172:16:4::/64 *[BGP/170] 00:53:45, localpref 100, from 192.168.28.1
AS path: 65000 I
> to fe80::205:86ff:fe71:5000 via se-1/0/1.0
26
A quick look at the extensive option reveals what the issue is::

lab@Tokyo-PE# run show route 2001:172:16:4::/64 extensive
2001:172:16:4::/64 (1 entry, 1 announced)
TSI:
KRT in-kernel 2001:172:16:4::/64 -> {indirect(262143)}
Page 0 idx 0 Type 1 val 92950bc
Nexthop: Self
AS path: [65412] 65412 I
Communities:
Path 2001:172:16:4:: from 192.168.28.1 Vector len 4. Val: 0
Address: 0x92697f8
Source: 192.168.28.1
Next hop: fe80::205:86ff:fe71:5000 via se-1/0/1.0, selected
Indirect next hop: 92d8000 262143
Task: BGP_65412.192.168.28.1+179
Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 5
AS path: 65000 I
Accepted
Localpref: 100
Router ID: 192.168.28.1
Protocol next hop: ::ffff:192.168.28.1 Metric: 20
Next hop: fe80::205:86ff:fe71:5000 via se-1/0/1.0
::ffff:192.168.28.1/128 Originating RIB: inet6.0
Nexthop: fe80::205:86ff:fe71:5000 via se-1/0/1.0
The only route available for BGP to resolve the next hop is the IS-IS route for the IPV4-mapped
configured in the previous lab under the loopback interface

lab@Tokyo-PE# run show route ::ffff:192.168.28.1
27

::ffff:192.168.28.1/128
*[IS-IS/18] 00:44:54, metric 20
> to fe80::205:86ff:fe71:5000 via se-1/0/1.0
To resolve this next hop BGP through the LSP between Tokyo and HongKong, BGP would need to
find a route for ::ffff:192.168.28.1 in the equivalent inet.3 routing table for IPv6, pointing to the
LSP.
At this point there is not such a route
Part 6: Enable IPv6 Tunneling over MPLS

Step 6.1
Enable IPv6 tunneling over your LSP and commit your configuration:

lab@Tokyo-PE# set ipv6-tunneling
commit complete
♦ What is the effect of this command? Enter the show route summary command. Are
there any new routing tables?
When you enter the show route summary command look towards the bottom of the
output. A new routing table called inet6.3 was created by the IPv6-tunneling command.
lab@Tokyo-PE> show route summary

Autonomous system number: 65412
Router ID: 192.168.21.1
Direct: 4 routes, 4 active
Local: 3 routes, 3 active
BGP: 4 routes, 4 active
Static: 4 routes, 4 active
IS-IS: 7 routes, 7 active
28

RSVP: 1 routes, 1 active
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
MPLS: 3 routes, 3 active
Local: 4 routes, 4 active
BGP: 10 routes, 10 active
IS-IS: 8 routes, 8 active
RSVP: 1 routes, 1 active
This statement allows IPv6 routes to be resolved over an MPLS network by converting all routes
stored in the inet.3 routing table to IPv4-mapped IPv6 addresses and then copying them into the
inet6.3 routing table. This routing table can be used to resolve next hops for both inet6 and inet6-
vpn routes. The routes are added to inet6.3
♦ You can check the contents of inet6.3 by entering the show route table inet6.3
command. What routes do you see in there?
inet6.3 contains IPv4-mapped representation of the loopback interfaces’ IPv4

addresses used to define the egress router for the different LSPs on your router. It is just
a conversion from inet.3 to inet6.3
lab@Tokyo-PE> show route table inet6.3

::ffff:192.168.28.1/128
*[RSVP/7/1] 00:02:27, metric 20
♦ Is BGP able to resolve the next hop of the IPv6 routes using this routing table?
Check the next hop of these routes and compare it with the entries in inet6.3
29
Now that inet6.3 exists, and is being populated with routes by RSVP, BGP should
be able to use the LSPs to perform next-hop resolution for IPv6 routes ☺
lab@Tokyo-PE> show route 2001:172:16:4::/64

2001:172:16:4::/64 *[BGP/170] 01:01:23, localpref 100, from 192.168.28.1
AS path: 65000 I
Looking good!!! It seems that now the IPv6 learned route uses the LSP for the fowarding! This is
because the BGP next-hop of the route could now be resolved through inet6.3
lab@Tokyo-PE> show route 2001:172:16:4::/64 extensive

2001:172:16:4::/64 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 92950bc
Nexthop: Self
AS path: [65412] 65412 I
Communities:
Address: 0x92697f8
Source: 192.168.28.1
Label TTL action: prop-ttl
...
lab@Tokyo-PE> show route ::ffff:192.168.28.1

::ffff:192.168.28.1/128
*[IS-IS/18] 00:51:55, metric 20
> to fe80::205:86ff:fe71:5000 via se-1/0/1.0
30

::ffff:192.168.28.1/128
*[RSVP/7/1] 00:05:37, metric 20
So, does it work at all? Knowing that a CE router has a BGP learned route to the loopback (actually
a /64 route that encompasses the loopback) of the remote CE, then a ping or traceroute should work
end-to-end CE to CE

PING6(56=40+8+8 bytes) 2001:10:0:4::2 --> 2001:192:168:51::1
^C
--- 2001:192:168:51::1 ping6 statistics ---
No joy. What do you think it could be happening??
Part 7: Allow IPv6 Traffic Across MPLS

Step 7.1
When IPv6 packets arrive at your PE router, the PE will check the IPv6 routing table (inet.6) for a
route to the destination. Suppose a packet destined to 2001:172:16:4::1 arrives at Tokyo. According
to the routing table shown on the previous page, the packet needs to be forwarded to 10.10.1.1 via
se-1/0/1.0 and a label of 300880 is to be pushed into the packet.
Suppose Tokyo forwards the packet this way and the packet travels across the network. P routes will
swap the labels according to the contents of mpls.0 table until the packet reaches the P router right
before the destination PE router (Sydney in this case). You can observe the process by connecting
to the P router and checking the mpls.0 table.
lab@Tokyo-PE> show route 2001:172:16:4::1 extensive

2001:172:16:4::/64 (1 entry, 1 announced)

...
...
31
We look now in the next hop router along the path which happens to the the Sydney P router. An
inspection on its mpls.0 table indicates that when a labeled packet with a value of 300880 comes in,
the operation to be taken is Pop:
[luis@js2 ~]$ telnet sydney

Trying 10.150.0.149...
Connected to sydney.lab2.cavellgroup.com (10.150.0.149).
Escape character is '^]'.
Sydney-P (ttyp0)
login: lab
Password: lab123
--- JUNOS 9.3R3.8 built 2009-05-12 22:33:43 UTC
lab@Sydney-P> show route table mpls.0 label 300880 extensive

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
300880 (1 entry, 1 announced)
TSI:
KRT in-kernel 300880 /52 -> {Pop }
*RSVP Preference: 7
Label operation: Pop
State: <Active Int>
...
Things fail when the packet arrives at Sydney-P and the label is popped. Now Sydney has an IPv6
packet in its hands and doesn’t know what to do with it. In our lab, the P routers have some internal
IPv6 routes, but only because one of our test scenarios was native IPv6 BGP. In a real service
provider scenario, it is unlikely that the P routers will have any IPv6 configuration at all. To solve the
problem, a second label must be added to the packet. After popping the outer label, Sydney would
still have a labeled packet to be forwarded to HongKong. HongKong will then pop this additional
label and perform a Layer 3 lookup in inet6.
In other words, the outer label will allow forwarding the traffic to the appropriate PE router, and the
inner label will identify a packet as IPv6. This inner label is called the explicit-null label for IPv6.
Appending this label must be configured under protocols BGP. You must make these modifications
under protocols BGP for your IBGP group and confirm that the explicit null label and the inet6
labeled unicast address family have been negotiated between you and your IBGP peers.
You must delete family inet6 unicast as both labeled-unicast and unicast families cannot be enabled
at the same time.
32
[edit]
lab@Tokyo-PE# delete family inet6 unicast
lab@Tokyo-PE# set family inet6 labeled-unicast explicit-null
commit complete
____________________________ Note__________________________
Routes will not be seen until the remote PE side does performs this step.
__________________________________________________________________
Step 7.2
Once the session is restored after your previous change, check the address families that your peer
has negotiated to other iBGP peers:
lab@Tokyo-PE> show bgp neighbor 192.168.28.1

Peer: 192.168.28.1+179 AS 65412 Local: 192.168.21.1+56524 AS 65412
Last Error: None
Export: [ send-statics-v4 NH ]
Options: <Preference LocalAddress AddressFamily Refresh>
Address families configured: inet-unicast inet6-labeled-unicast
NLRI inet6-labeled-unicast: ExplicitNull
Number of flaps: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast inet6-labeled-unicast
NLRI advertised by peer: inet-unicast inet6-labeled-unicast
NLRI for this session: inet-unicast inet6-labeled-unicast
...
♦ After changing your configuration, check the same route you checked on the
previous part, using again the extensive switch to observe the details. What label
would be used to send traffic to that destination?
33
The following example shows the next-hop resolution details and highlights the labels
that will be used to reach the PE router advertising the route.
lab@Tokyo-PE> show route 2001:172:16:4::1 extensive

2001:172:16:4::/64 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 9295b20
Nexthop: Self
AS path: [65412] 65412 I
Communities:
Address: 0x92696d8
Source: 192.168.28.1
Label operation: Push 2, Push 300880(top)
Label TTL action: prop-ttl, prop-ttl(top)
Push 2
Indirect next hop: 93bc000 262143
Task: BGP_65412.192.168.28.1+179
Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 5
AS path: 65000 I
Accepted
Route Label: 2
Localpref: 100
Router ID: 192.168.28.1
Protocol next hop: ::ffff:192.168.28.1 Metric: 20
Push 2
Indirect next hop: 93bc000 262143
Next hop: via se-1/0/1.0 weight 0x1
::ffff:192.168.28.1/128 Originating RIB: inet6.3
Nexthop: via se-1/0/1.0
34
lab@Tokyo-PE> show route table inet6.3 ::ffff:192.168.28.1

::ffff:192.168.28.1/128
*[RSVP/7/1] 00:50:00, metric 20
Part 8: Verify Network Operation

Step 8.1
Trace and ping from your CE router to other CE routers. Source your packets using your loopback
interface global IPv6 address.

PING6(56=40+8+8 bytes) 2001:10:0:4::2 --> 2001:192:168:51::1
16 bytes from 2001:192:168:51::1, icmp_seq=0 hlim=62 time=10.925 ms
^C
--- 2001:192:168:51::1 ping6 statistics ---
round-trip min/avg/max/std-dev = 9.594/10.191/10.925/0.552 ms
lab@Denver-CE_A1> traceroute 2001:192:168:51::1 source 2001:192:168:50::1

traceroute6 to 2001:192:168:51::1 (2001:192:168:51::1) from 2001:192:168:50::1, 64
hops max, 12 byte packets
1 2001:10:0:4::1 (2001:10:0:4::1) 4.563 ms 4.807 ms 4.332 ms
2 * * *
3 2001:10:0:33::2 (2001:10:0:33::2) 7.749 ms 6.329 ms 7.749 ms
4 2001:192:168:51::1 (2001:192:168:51::1) 6.817 ms 8.259 ms 7.179 ms
STOP
You have completed IPv6 6PE lab !
35

Lab6 Exercise IPv6 6PE Per POD

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Lab6 Exercise IPv6 6PE Per POD

Caricato da

Copyright:

Formati disponibili

Juniper IPv6 lab exercise: 6PE

Lab 6: 6PE IPv4 BGP Sessions Carrying IPv6 routes

10.10.x.y/24 = Serial Interfaces

AS 65001 eBGP eBGP AS 65001

Lab 6: 6PE IPv4 BGP Sessions Carrying IPv6 routes

10.10.x.y/24 = Serial Interfaces

AS 65002 eBGP eBGP AS 65002

Part 1: Restore IPv6 bgp native configuration

Part 2: Configure iBGP over IPv4

Router Loopback address

[edit protocols bgp group v4-peers]

Go ahead and commit your changes:

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

♦ Are all of your BGP session established?

Yes they are.

[edit protocols bgp group v4-peers]

Last traffic (seconds): Received 3 Sent 6 Checked 51

Tokyo HongKong London Amsterdam SanJose Montreal

Issue the following commands for your static routes configuration:

Display your static routes for confirmation:

Display your policy for confirmation:

[edit policy-options policy-statement send-statics-v4]

[edit policy-options policy-statement send-statics-v4]

Every router should have 8 x 200.x.y/24 routes in its inet.0 table

Part 3: Configure the Advertisement of IPv6 Routes over your IBGP-IPv4

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

♦ Is the inet-unicast family still enabled for the session?

[edit protocols bgp group v4-peers]

♦ Are you still receiving IPv4 routes from other PE routers?

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

♦ Are you advertising any IPv6 routes to your IBGP peers?

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

[edit protocols bgp group v4-peers]

♦ What is the BGP next-hop of those hidden IPv6 routes?

In the case of the route 2001:172:16:4::/64 the BGP next-hop happens to be

[edit protocols bgp group v4-peers]

___________________________ Note 2 !! ________________________

Part 4: Repair unusable routes

Router New IPv6 address for lo0.0

San Jose ::ffff:192.168.8.1

[edit policy-options policy-statement NH]

[edit interfaces lo0]

♦ Is your router advertising its ::ffff:192.168.x.1 address on the IGP ?

lab@Tokyo-PE> show isis database Tokyo detail

No, hidden routes are gone now ☺

lab@Tokyo-PE> show route hidden

Yes. There should be 8x 200.#.#/24 routes in inet.0.

lab@Tokyo-PE> show route 200/8 terse | match /24 | count

lab@Tokyo-PE> show route 200/8 terse

Yes. There should be 8x 2001:172.#.#/64 routes in inet6.0.

lab@Tokyo-PE> show route 2001:172::/32 terse | match /64 | count

lab@Tokyo-PE> show route 2001:172::/32 terse

___ Note 2 !!