IPv6
- IPv6 is the solution for many limitations in IPv4. However, IPv6 is not yet vastly deployed due
to the overwhelming tasks of readdressing and upgrading of existing networks and applications.
- Below are some benefits of implementing IPv6:
i) Larger address space provides better support for more granular hierarchical addressing,
greater number of addressable nodes, and simpler autoconfiguration of addresses.
ii) The simpler and fixed-size header enables better routing efficiency and performance.
iii) Various transition mechanisms, eg: dual stack, tunneling, and translation allow existing
IPv4 networks to coexist with IPv6 features.
iv) Provides native support for new mobility and security standards – Mobile IP and IPsec.
v) Security and QoS can be implemented more efficiently with end-to-end connectivity
instead of intermediate address translations (IPv6 eliminates the need for deploying NAT).
- Mobility provides roaming service for mobile devices (eg: IP phones) without interrupting the
current connection. Mobile IP is available for both IPv4 (as an add-in) and IPv6 (built-in).
- IPsec ensures better security (integrity, authentication, and confidentiality) for IPv6 networks.
It is available for IPv4 and is mandatory for IPv6 – it is enabled and available on all IPv6 nodes.
IPsec support and implementation is a mandatory part of IPv6 but is not an integral part of IPv4.
However, due to the slow uptake of IPv6, IPsec is commonly used to secure IPv4 traffic.
- A node is a device that implements IPv6, be it a host or a router.
A host is a node that is not a router.
A link is equivalent to a network or a broadcast domain.
A prefix is equivalent to a subnet.
IPv6 Header Format
- The IPv6 header has been simplified to have fewer fields for easier, faster and efficient packet
processing, enhanced performance, and routing efficiency.
- With the design and implementation of the fewer fields and 64-bit aligned fields, IPv6 is able to
take advantage of the upcoming 64-bit processors for faster and efficient processing.
- IPv6 basic header has a fixed length of 40 bytes.
- Since most current link-layer technologies are relatively reliable and perform error detection,
the IP header checksum is considered redundant and hence has been removed. Without the IP
header checksum, both the connection and connectionless transport layer protocols are required
to perform error detection and recovery. The removal of the IP checksum field further reduces
the network layer processing time, as routers can concentrate solely on forwarding packets.
- If checksuming is required, it can be done via an AH header which provides cryptographically
strong authentication and eventually a checksum for the whole packet.
IPv6 Extension Headers
- Instead of having the Options field as in IPv4 header, IPv6 attaches extension headers to the end
of a basic or extension header, with the 8-bit Next Header field specifying the next extension
header if any. The use of extension headers allows faster processing and protocol evolution.
- Extension headers are 64-bit in length and the number of extension headers in an IPv6 packet is
variable. Extension headers are daisy-chained one after another with the Next Header field of
the previous basic or extension header specifies the current extension header. The last extension
header (or the basic header if extension header is not used) has a Next Header field specifies a
transport layer protocol, eg: TCP, UDP.
- The use of extension headers allows end-to-end security, as no firewalls and NAT are involved.
- Mobility provides roaming service for mobile devices (eg: IP phones) without interrupting the
current connection. The IPv6 routing header allows an end system to change its source IP address
with a stable home address, and hence allows the roaming address to maintain mobility.
- Cisco IOS Mobility IP is a tunneling-based solution that uses Cisco GRE or IP-in-IP tunnel.
Tunneling allows a router on a device’s home subnet to transparently forward IP packets to the
roaming devices. IPv4 offers Mobile IP via triangle routing, where data is tunneled back to the
home network before being forwarded to the final destination. However, this approach is less
efficient than Mobile IPv6. GRE – Generic Routing Encapsulation.
- IPv6 has 6 types of extension headers. When multiple extension headers are used in the same
packet, the order of the extension header as specified in RFC 1883 is as below:
Note: The source node must follow this order; while the destination node may receive in any order
Sabtu, 31 Oktober 2009
BGP Troubleshooting Flow
Troubleshooting BGP Route Advertisement
Troubleshooting Multihoming Outbound
Troubleshooting Multihoming Inbound
Troubleshooting Routes Missing from the Routing Table
Troubleshooting BGP Neighbor Establishment
bgp main troubleshooting
Troubleshooting Multihoming Outbound
Troubleshooting Multihoming Inbound
Troubleshooting Routes Missing from the Routing Table
Troubleshooting BGP Neighbor Establishment
bgp main troubleshooting
Curhatan
tanpa disadari waktu terus berjalan, berlomba oleh usia, impian belum terwujud "how to become CCIE " wow.. jalan berliku musti dihadapi. dunia network harus tidak tergantung dlm satu "konteks" hari ini saya mendapat pelajaran berharga "not just the only one" saatnya mencoba memikirkan secara luas. apa selanjutnya ?.
time to play with juniper network. JNCIS-M saya datang..... hehehehe..
mungkin tahun depan akan di coba utk CEH certified.
thinks...thinks..thinks...and do it...
sambil ngumpulin duit buat nge-lab CCIE :-P
time to play with juniper network. JNCIS-M saya datang..... hehehehe..
mungkin tahun depan akan di coba utk CEH certified.
thinks...thinks..thinks...and do it...
sambil ngumpulin duit buat nge-lab CCIE :-P
MPLS Concepts
The two major elements of MPLS architecture are the control plane and the data plane.
- The control plane exchanges routing information (with routing protocols such as OSPF) and labels with protocols such as LDP or TDP
- The data plane is the forwarding engine
MPLS labels maintain how to forward information. They function differently depending on whether MPLS is functioning in frame-mode or cell-mode.
- In frame-mode MPLS labels are 32-bit fields inserted between the Layer 2 and Layer 3 headers. These are broken into the following
- 20-bit label
- 3-bit experimental field
- 1 bit bottom-of-stack indicator
- 8-bit TTL field
- In cell-mode the ATM header is the label
A label switch router (LSR) is a device that forwards based on labels.
An edge LSR labels and removes labels from packets.
LSRs that perform cell-mode MPLS are divided into the following categories:
- ATM LSRs if they are ATM switches. All interfaces are enabled for MPLS, and forwarding is done based only on labels.
- ATM edge LSRs if they are routers connected to an MPLS-enabled ATM network.
Forwarding equivalence class (FEC) describes the forwarding characteristic of a packet, such as the destination IP.
MPLS is used for the following applications:
- Unicast IP routing
- Multicast IP routing
- MPLS traffic engineering provides more efficient link use
- Differentiated Quality of Service
- MPLS VPNs - Separate customer routing information across the MPLS backbone
- Any Transport over MPLS - Transport Layer 2 packets over an MPLS backbone
Label Distribution Protocol (LDP) and Tag Distribution Protocol (TDP) exchange labels and store the information in the label information base (LIB).
A label is added to the IP forwarding table (forwarding information base, or FIB) to map an IP prefix to a next-hop label.
A locally generated label is added to the label forwarding information base (LFIB) and mapped to a next-hop label.
An LSP is a sequence of LSRs that forward labeled packets for a particular FEC. Each LSR swaps the top label in a packet traversing the LSP. An LSP is similar to Frame Relay or ATM virtual circuits. In cell-mode MPLS, an LSP is a virtual circuit.
Impacts of IP Aggregation
Aggregation (or summarization) should not be used on ATM LSRs because it breaks LSPs in two, which means that ATM switches would have to perform Layer 3 lookups.
Aggregation should also not be used where an end-to-end LSP is required. Typical examples of networks that require end-to-end LSPs are the following:
-
A transit BGP autonomous system (AS) where core routers are not running BGP
-
An MPLS VPN backbone
-
An MPLS-enabled ATM network
- A network that uses MPLS TE
Frame-Mode Loop Detection
The TTL functionality in MPLS is equivalent to that of traditional IP forwarding. Furthermore, when an IP packet is labeled, the TTL value from the IP header is copied into the TTL field in the label. This is called “TTL propagation.”
TTL propagation can be disabled to hide the core routers from the end users. Disabling TTL propagation causes routers to set the value 255 into the TTL field of the label when an IP packet is labeled.
If TTL propagation is disabled, it must be disabled on all routers in an MPLS domain to prevent unexpected behavior.
TTL can be optionally disabled for forwarded traffic only, which allows administrators to use traceroute from routers to troubleshoot problems in the network.
Penultimate Hop Popping
PHP optimizes MPLS performance by reducing the number of table lookups on the egress router.
PHP is not supported on ATM devices because a label is part of the ATM cell payload and cannot be removed by the ATM switching hardware.
Per-Platform Label Allocation
There are two possible approaches for assigning labels to networks:
-
Per-platform label allocation: One label is assigned to a destination network and announced to all neighbors. The label must be locally unique and valid on all incoming interfaces. This is the default operation in frame-mode MPLS.
- Per-interface label allocation: Local labels are assigned to IP destination prefixes on a per-interface basis. These labels must be unique on a per-interface basis.
MPLS Convergence
The overall convergence in an MPLS network is not affected by LDP convergence when there is a link failure.
Frame-mode MPLS uses liberal label retention mode, which enables routers to store all received labels, even if they are not being used.
These labels can be used, after the network convergence, to enable immediate establishment of an alternative LSP tunnel.
Cell-Mode Issues
Cell-mode MPLS is significantly different from frame-mode MPLS because of some ATM-specific requirements:
-
ATM uses cells and not frames. A single packet may be encapsulated into multiple cells. Cells are a fixed length, which means that normal labels cannot be used because they would increase the size of a cell. The virtual path identifier/virtual channel identifier (VPI/VCI) field in the ATM header is used as the MPLS label. An LSP tunnel is therefore called a virtual circuit in ATM terminology.
- ATM switches and routers usually have a limited number of virtual circuits that they can use. MPLS establishes a full mesh of LSP tunnels (virtual circuits), which can result in an extremely large number of tunnels.
Because ATM switches cannot forward IP packets, labels cannot be asynchronously assigned and distributed.
Instead, the router initiates an ordered sequence of requests on the upstream side of the ATM network.
It is not until the request is answered with the label and assigned to destinations in the IP routing table that the forwarding table is populated.
An ordered sequence of downstream requests is followed by an ordered sequence of upstream replies. This type of operation is called downstream-on-demand allocation of labels.
Two virtual circuits can merge into one. Standard ATM virtual switching hardware does not support this situation, and as a result, segmented packets from the two sources may become interleaved.
There are two possible solutions to this problem:
-
Allocate a new downstream label for each request. This solution would result in a greater number of labels.
- Buffer the cells of the second packet until all cells of the first packet are forwarded. This solution results in an increased delay of packets because of buffering.
The major benefit of VC merge is that it minimizes the number of labels (VPI/VCI values) needed in the ATM part of the network.
The major drawbacks to VC merge are as follows:
-
Buffering requirements increase on the ATM LSR.
-
There is an increase in delay and jitter in the ATM network.
- ATM networks under heavy load become more like frame-based networks.
Loop Detection in Cell-Mode MPLS Networks
Cell-mode MPLS uses the VPI/VCI fields in the ATM header to encode labels. These two fields do not include a TTL field. Therefore, cell-mode MPLS must use other ways of preventing routing loops.
LDP uses a hop-count TLV (type, length, value) attribute to count hops in the ATM part of the MPLS domain.
This hop count can be used to provide correct TTL handling on ATM edge LSRs on behalf of ATM LSRs that cannot process IP packets.
A maximum limit in the number of hops can also be set.
Per-Interface Label Allocation
Cell-mode MPLS defaults to using per-interface label space because ATM switches support per-interface VPI/VCI values to encode labels.
Therefore, if a single router has two parallel links to the same ATM switch, two LDP sessions are established and two separate labels are requested.
Label Distribution Parameters
The two label space options are:
-
Per-interface label space, where labels must be unique for a specific input interface
-
Per-platform label space, where labels must be unique for the entire platform (router)
The two options for label generation and distribution are as follows:
-
Unsolicited downstream distribution of labels is used in frame-mode MPLS, where all routers can asynchronously generate local labels and propagate them to adjacent routers.
-
Downstream-on-demand distribution of labels is used in cell-mode MPLS, where ATM LSRs have to request a label for destinations found in the IP routing table.
Another aspect of label distribution focuses on how labels are allocated:
-
Frame-mode MPLS uses independent control mode, where all routers can start propagating labels independently of one another.
-
Cell-mode MPLS requires LSRs to already have the next-hop label if they are to generate and propagate their own local labels. This option is called ordered control mode.
The last aspect of label distribution looks at labels that are received but not used:
-
Frame-mode MPLS may result in multiple labels being received but only one being used. Unused labels are kept, and this mode is usually referred to as liberal label retention mode.
- Cell-mode MPLS keeps only labels that it previously requested. This mode is called conservative label retention mode.
LDP Session Establishment
LDP is a standard protocol used to exchange labels between adjacent routers. TDP) is a Cisco proprietary protocol that has the same functionality as LDP.
LDP periodically sends hello messages. The hello messages use UDP packets with a multicast destination address of 224.0.0.2 (“all routers on a subnet”) and destination port number of 646 (711 for TDP).
If another router is enabled for LDP (or TDP), it will respond by opening a TCP session with the same destination port number (646 or 711).
ATM LSRs establish the IP adjacency across the MPLS control virtual circuit, which by default has a VPI/VCI value of 0/32.
An IP routing protocol and LDP (or TDP) use this control virtual circuit to exchange IP routing information and labels.
Some Cisco devices use the Virtual Switch Interface (VSI) protocol to create entries in the LFIB table (ATM switching matrix of the data plane) based on the information in the LIB table (control plane). This protocol is used to dynamically create virtual circuits for each IP network.
How hackers find your weak spots
Stealing passwords: In this common maneuver, the hacker uses information from a social networking profile to guess a victim's password reminder question. This technique was used to hack Twitter and break into Sarah Palin's e-mail.
Friending: In this scenario, a hacker gains the trust of an individual or group and then gets them to click on links or attachments that contain malware that introduces a threat, such as the ability to exploit a weakness in a corporate system. For example, says Netragard CTO Adriel Desautels, he might strike up an online conversation about fishing and then send a photo of a boat he's thinking of buying.
Impersonation/social network squatting: In this case, the hacker tweets you, friends you or otherwise contacts you online using the name of someone you know. Then he asks you to do him a favor, like sending him a spreadsheet or giving him data from "the office." "Anything you see on a computer system can be spoofed or manipulated or augmented by a hacker," says Desautels.
Posing as an insider: Imagine all the information you could extract from an unknowing employee if you posed as an IT help desk worker or contractor. "Roughly 90% of the people we've successfully exploited during [vulnerability assessments for clients] trusted us because they thought we worked for the same company as them," Desautels says.
On the Netragard blog, he describes an exploit in which a Netragard worker posed as a contractor, befriended a group of the client's workers and set up a successful phishing scheme through which he gleaned employee credentials, eventually gaining entry to the entire corporate infrastructure.
source : computerworld.com
Troubleshooting uBR Cable Modems PART1
Troubleshooting Cable Modem State
The first and most useful command to use at the CMTS is show cable modem:
limbad# show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 4 online(d) 2814 −0.50 6 0 10.1.1.20 0030.96f9.65d9
Cable2/0/U0 5 online(pt) 2290 −0.25 5 0 10.1.1.25 0050.7366.2223
Cable2/0/U0 6 offline 2287 −0.25 2 0 10.1.1.26 0050.7366.2221
Cable2/0/U0 7 online(d) 2815 −0.25 6 0 10.1.1.27 0001.9659.4461
The state field above shows what status the CM is in. The field can have the following values:
CM States (as shown in the CMTS) Meaning
offline Cable modem considered offline
init(r1) Cable modem sent initial ranging
init(r2) Cable modem is ranging
init(rc) Cable modem ranging complete
init(d) Dhcp request received
init(i) Dhcp reply received; IP address assigned
init(t) TOD exchange started
init(o) Option file transfer started
online Cable modem registered, enabled for data
online(d) Cable modem registered, but network
access for the cable modem is disabled
online(pk) Cable modem registered, BPI enabled
and KEK assigned
online(pt) Cable modem registered, BPI enabled
and TEK assigned
reject(pk) KEK modem key assignment rejected
reject(pt) TEK modem key assignment rejected
reject(m) Cable modem did attempt to register;
registration was refused due to bad MIC
(Message Integrity Check )
reject(c) Cable modem did attempt to register;
registration was refused due to bad COS
(Class of Service)
The first and most useful command to use at the CMTS is show cable modem:
limbad# show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 4 online(d) 2814 −0.50 6 0 10.1.1.20 0030.96f9.65d9
Cable2/0/U0 5 online(pt) 2290 −0.25 5 0 10.1.1.25 0050.7366.2223
Cable2/0/U0 6 offline 2287 −0.25 2 0 10.1.1.26 0050.7366.2221
Cable2/0/U0 7 online(d) 2815 −0.25 6 0 10.1.1.27 0001.9659.4461
The state field above shows what status the CM is in. The field can have the following values:
CM States (as shown in the CMTS) Meaning
offline Cable modem considered offline
init(r1) Cable modem sent initial ranging
init(r2) Cable modem is ranging
init(rc) Cable modem ranging complete
init(d) Dhcp request received
init(i) Dhcp reply received; IP address assigned
init(t) TOD exchange started
init(o) Option file transfer started
online Cable modem registered, enabled for data
online(d) Cable modem registered, but network
access for the cable modem is disabled
online(pk) Cable modem registered, BPI enabled
and KEK assigned
online(pt) Cable modem registered, BPI enabled
and TEK assigned
reject(pk) KEK modem key assignment rejected
reject(pt) TEK modem key assignment rejected
reject(m) Cable modem did attempt to register;
registration was refused due to bad MIC
(Message Integrity Check )
reject(c) Cable modem did attempt to register;
registration was refused due to bad COS
(Class of Service)
The Passive State
The Passive State
The passive state involves operating systems with built-in security utilities. These utilities
can be quite effective when enabled, but remain worthless until the system administrator
activates them. In the passive state, these utilities are never activated, usually because the
user is unaware that they exist. Again, the source of the problem is the same: The user or
system administrator lacks adequate knowledge of the system.
To understand the passive state, consider logging utilities. Many networked operating
systems provide good logging utilities. These comprise the cornerstone of any
investigation. Often, these utilities are not set to active in a fresh installation. (Vendors
might leave this choice to the system administrator for a variety of reasons. For example,
certain logging utilities consume space on local drives by generating large text or
database files. Machines with limited storage are poor candidates for conducting heavy
logging.) Because vendors cannot guess the hardware configuration of the consumer's
machine, logging choices are almost always left to the end-user.
Other situations that result in passive-state insecurity can arise: Situations where user
knowledge (or lack thereof) is not the problem. For instance, certain security utilities are
simply impractical. Consider security programs that administer file-access privileges
(such as those that restrict user access depending on security level, time of day, and so
forth).
Vendor Response
• When the affected application is comprehensively tied to the operating-system source
• When the application is very widely in use or is a standard
• When the application is third-party software and that third party has poor support, has gone out of business, or is otherwise unavailable
System Flaws or Deficiency of Vendor Response
System flaws or deficiency of vendor response are matters beyond the end-user's control.
• Work improperly (under either normal or extreme conditions)
• Allow crackers to exploit that weakness (or improper operation) to damage or gain control of a
system
In these instances, a patch (or other solution) can provide temporary relief. However, for
this system to work effectively, all users must know that the patch is available. Notifying
the public would seem to be the vendor's responsibility and, to be fair, vendors post such
patches to security groups and mailing lists. However, vendors might not always take the
The passive state involves operating systems with built-in security utilities. These utilities
can be quite effective when enabled, but remain worthless until the system administrator
activates them. In the passive state, these utilities are never activated, usually because the
user is unaware that they exist. Again, the source of the problem is the same: The user or
system administrator lacks adequate knowledge of the system.
To understand the passive state, consider logging utilities. Many networked operating
systems provide good logging utilities. These comprise the cornerstone of any
investigation. Often, these utilities are not set to active in a fresh installation. (Vendors
might leave this choice to the system administrator for a variety of reasons. For example,
certain logging utilities consume space on local drives by generating large text or
database files. Machines with limited storage are poor candidates for conducting heavy
logging.) Because vendors cannot guess the hardware configuration of the consumer's
machine, logging choices are almost always left to the end-user.
Other situations that result in passive-state insecurity can arise: Situations where user
knowledge (or lack thereof) is not the problem. For instance, certain security utilities are
simply impractical. Consider security programs that administer file-access privileges
(such as those that restrict user access depending on security level, time of day, and so
forth).
Vendor Response
Vendor response has traditionally been good, but this shouldn't give you a false sense of
security. Vendors are in the business of selling software. To them, there is nothing fascinating about someone discovering a hole in the system. At best, a security hole represents a loss of revenue or prestige. Accordingly, vendors quickly issue assurances to allay users' fears, but actual corrective action can sometimes be long in coming.
The reasons for this can be complex, and often the vendor is not to blame. Sometimes, immediate corrective action just isn't feasible, such as the following: • When the affected application is comprehensively tied to the operating-system source
• When the application is very widely in use or is a standard
• When the application is third-party software and that third party has poor support, has gone out of business, or is otherwise unavailable
System Flaws or Deficiency of Vendor Response
System flaws or deficiency of vendor response are matters beyond the end-user's control.
Although vendors might argue this point furiously, here's a fact: These factors are the second most common source of security problems. Anyone who subscribes to a bug mailing list knows this. Each day, bugs or programming weaknesses are found in network software. Each day, these are posted to the Internet in advisories or warnings. Unfortunately, not all users read such advisories.
System flaws needn't be classified into many subcategories here. It's sufficient to say that a system flaw is any element of a program that causes the program to
• Work improperly (under either normal or extreme conditions)
• Allow crackers to exploit that weakness (or improper operation) to damage or gain control of a
system
In these instances, a patch (or other solution) can provide temporary relief. However, for
this system to work effectively, all users must know that the patch is available. Notifying
the public would seem to be the vendor's responsibility and, to be fair, vendors post such
patches to security groups and mailing lists. However, vendors might not always take the
extra step of informing the general public. In many cases, it just isn't cost effective.
ORIGINATION A PREFIX WITHIN BGP
Three methods can be used to originate a prefix in BGP
1. Configuring the BGP "Network" command
2. Redistribution from routing sources other than EGP
3. Redistribution from EGP (the inter-domain routing protocol Exterior Gateway Protocol)
Three Methods of originating BGP updates correspond with the three and only three origin code types set by BGP. the origin code is mandatory transitive BGP attribute. A brief description of each origin code is provided below:
> "i" ORIGIN is IGP; this shows that the prefix was originated via network statement.
> "?" ORIGIN is incomplete, this shows that the prefix was originated via redistribution.
> "e" ORIGIN is EGP, this shows that the prefix was originated from an EGP routing process.
1. Configuring the BGP "Network" command
2. Redistribution from routing sources other than EGP
3. Redistribution from EGP (the inter-domain routing protocol Exterior Gateway Protocol)
Three Methods of originating BGP updates correspond with the three and only three origin code types set by BGP. the origin code is mandatory transitive BGP attribute. A brief description of each origin code is provided below:
> "i" ORIGIN is IGP; this shows that the prefix was originated via network statement.
> "?" ORIGIN is incomplete, this shows that the prefix was originated via redistribution.
> "e" ORIGIN is EGP, this shows that the prefix was originated from an EGP routing process.
Jumat, 30 Oktober 2009
MPLS Troubleshooting
Control plane
PE1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 50.50.50.2 YES NVRAM up up
Serial0/0 150.1.1.34 YES manual up up
Serial0/1 150.1.1.18 YES manual up up
Serial0/2 unassigned YES manual administratively down down
Serial0/3 192.168.1.49 YES manual up up
Loopback0 192.168.1.17 YES manual up up
PE1#show ip cef summary
IP CEF with switching (Table Version 18), flags=0x0
18 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 6
44 leaves, 46 nodes, 51304 bytes, 52 inserts, 8 invalidations
0 load sharing elements, 0 bytes, 0 references
universal per-destination load sharing algorithm, id C55C895D
3(0) CEF resets, 0 revisions of existing leaves
Resolution Timer: Exponential (currently 1s, peak 1s)
0 in-place/0 aborted modifications
refcounts: 12657 leaf, 12544 node
Table epoch: 0 (18 entries at this epoch)
Adjacency Table has 5 adjacencies
PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 192.168.1.81/32 0 Se0/3 point2point
17 Pop tag 192.168.1.64/28 0 Se0/3 point2point
18 16 192.168.1.33/32 0 Se0/3 point2point
19 Untagged 10.1.1.16/28[V] 0 Se0/1 point2point
20 Untagged 10.1.1.49/32[V] 0 Se0/1 point2point
21 Aggregate 150.1.1.16/28[V] 0
22 Untagged 10.2.1.16/28[V] 0 Se0/0 point2point
23 Untagged 10.2.1.49/32[V] 0 Se0/0 point2point
24 Aggregate 150.1.1.32/28[V] 0
PE1#sh mpls interfaces
Interface IP Tunnel Operational
Serial0/3 Yes (ldp) No Yes
PE1#show mpls forwarding-table detail | in 150.1.1.16
21 Aggregate 150.1.1.16/28[V] 0
PE1#show mpls forwarding-table detail | b 150.1.1.16
21 Aggregate 150.1.1.16/28[V] 0
MAC/Encaps=0/0, MRU=0, Tag Stack{}
VPN route: Customer_A
No output feature configured
Per-packet load-sharing
PE1#show mpls forwarding-table vrf Customer_A 150.1.1.16 28
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 Aggregate 150.1.1.16/28[V] 0
PE1#show mpls forwarding-table vrf Customer_A 150.1.1.16 28 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 Aggregate 150.1.1.16/28[V] 0
MAC/Encaps=0/0, MRU=0, Tag Stack{}
VPN route: Customer_A
No output feature configured
Per-packet load-sharing
PE1#show tag-switching tdp parameters
Protocol version: 1
Downstream tag generic region: min tag: 16; max tag: 100000
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery directed hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for directed sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
PE1#show mpls ldp parameters
Protocol version: 1
Downstream label generic region: min label: 16; max label: 100000
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
Langganan:
Postingan (Atom)