Firewall Security-Level

That is my personal primary Safety measures Publish regarding Cisco PIX/ASA firewalls. To start with, what exactly firewall? Practically, throughout real life, a firewall as part of a making, is employed to you personally guessed the item: guard the particular making from flames.: ) A similar can be applied in the social networking earth. A new firewall is usually a gadget of which inhibits unauthorized entry as well as will allow official having access to a system. A new firewall may possibly perform intended for box selection, proxy server as well as stateful box selection. Cisco PIX/ASA devices be stateful box selection devices, which generates a stateful link kitchen table in order to confirm the particular connections.

A new firewall inhibits entry on the untrusted system towards the reliable system. The interface of the firewall may possibly participate in the particular untrusted or maybe the particular reliable. The interface of which belongs to the reliable system is normally called the lining interface and also the untrusted one is the outdoors interface. Security-levels from 0-100 shows the quality of confidence with an interface. The bigger the quantity a lot more reliable the particular interface. The principle throughout security-level is usually that the greater stability stage can easily have access to a reduced stability stage, the bottom stability stage will not have access to a higher stability stage and is impeded by default. Interfaces using the same stability levels are generally impeded too.

Why don't we configure interfaces as well as enables observe how security-levels are generally put on automatically as well as by hand. I'm by using a PICS firewall.

Initial enables configure an outdoor interface.


petesfirewall(config)# interface ethernet0
petesfirewall(config-if)# nameif external
INFO: Safety measures stage intended for "outside" established in order to 0 by default.

The "nameif" control is actually used to label the interface. Quite apparent isn't the item?: ) Notice that once we referred to as the particular interface "outside", Cisco automatically established the particular security-level in order to 0 which means their untrusted. Subsequent we configure an internal interface.

petesfirewall(config-if)# interface ethernet1
petesfirewall(config-if)# nameif interior
INFO: Safety measures stage intended for "inside" established in order to 100 by default.

The PICS now configures the particular stability stage simply by 100 so this means their a trusted interface. For that reason, visitors from ethernet1 in order to ethernet0 is usually authorized by default nevertheless visitors from ethernet0 in order to ethernet1 is not. That is wherever incoming access-list is available in permitting visitors from the untrusted interface to some reliable one.

We will now configure the interface referred to as "webservers". You need to use virtually any label you enjoy mind you. Why don't we give the item a security-level involving 62.

petesfirewall(config-if)# interface ethernet2
petesfirewall(config-if)# nameif webservers
INFO: Safety measures stage intended for "webservers" established in order to 0 by default.
petesfirewall(config-if)# security-level 62

Notice that virtually any interface label aside from "inside" is usually automatically provided a 0 security-level value. The "security-level" control is employed in order to designate by hand a stability stage for an interface. Ethernet2 by default can easily entry Ethernet0 nevertheless cannot entry Ethernet1, since the other carries a greater security-level compared to ex-. The "show nameif" control is usually a very useful control to show off the particular labels of the interfaces like the security-levels.


petesfirewall(config)# show nameif
Interface Label Safety measures
Ethernet0 external 0
Ethernet1 interior 100
Ethernet2 webservers 62

As you're able discover, in the PICS firewall the particular show control is usually accepted in contrast to in the routers which will not recognize show requires in the global-configuration mode. For all those have been establishing routers, establishing in order to establishing firewalls would be simple. All things considered, their still Cisco.: )

Eventually, at times we have a must permit having access to interfaces using the same security-level. The control under, will allow these kinds of entry.


petesfirewall(config)# same-security-traffic allow inter-interface.

Read More

MPLS Basics

On the list of wonderful improvements to further improve WAN products and services can be MPLS. Formerly, it was designed to address the down sides with ATM communities and due to Cisco and IETF, it has progressed from what it can be nowadays.

MPLS (Multiprotocol Tag Switching) is a process that uses product labels regarding box changing. MPLS can be agnostic associated with Layer 1 as well as Layer 2 practices and can be used with any good links. That inserts a new 32-bit content label in between your Layer 2 and Layer 3 headers that called it being a Layer 2. 5 process. These types of product labels variety variety can be 0-1, 048, 575. Product labels 0-15 regarding earmarked requirements which means usuable variety can be 16-1, 048, 575. The defaul variety within Cisco routers can be via of sixteen : 100, 000 that is suitable regarding huge establishments.

MPLS has a operating IGP direction-finding process with a whole direction-finding stand. CEF should also become help mainly because FIB (Forwarding Info Base) and adjancency furniture are needed to construct your LFIB (Label Forwarding Info Base). FIB is in charge of maintaning the subsequent hops for your routes within the direction-finding stand even though adjacency stand is made for your Layer 2 reword to ensure that repeating ARP asks is going to be definitely avoided.

The process associated with how MPLS is effective starts off from the direction-finding process making your IP direction-finding stand. From then on, based on the direction-finding stand your MPLS allowed router can now build its own mapping in between vacation spot ip with a content label. Additionally, making use of LDP (Label Syndication Protocol) your LSR's (Label Switch Routers or perhaps MPLS-enabled routers) in the MPLS communities discuss their issued product labels. Ultimately, your LSR's build your LIB (Label Info Base), LFIB, and FIB based on the product labels that they gotten.

How you can Configure MPLS inside a Cisco Router

We have now beneath an easy diagram of the circle which is to be used for this specific illustration. We all can give attention to the fundamentals associated with setup, many indicate requires and some "what if" examples.


Dynamips Configuration


autostart = accurate
ghostios = accurate
sparsemem = accurate
# MPLS Basics

[localhost]

[[7200]]
picture = \Program Files\Dynamips\images\c7200-jk9o3s-mz. 124-7a. can
npe = npe-400
random access memory = 160

[[ROUTER R1]]
Se1/0 = R2 Se1/0
Se1/1 = R3 Se1/0

[[ROUTER R2]]
Se1/1 = R3 Se1/1

[[ROUTER R3]]


Fundamental Designs

Start off dynamips and implement the basic settings under required for that case in point. Simply just duplicate and stick everything under and it should be great.


R1
!
user interface Serial1/0
ip target 192. 168. 12. 1 255. 255. 255. 0
simply no turn
!
user interface Serial1/1
ip target 192. 168. 13. 1 255. 255. 255. 0
simply no turn

!
router ospf 1
log-adjacency-changes
multilevel 0. 0. 0. 0 255. 255. 255. 255 region 0

R2
!
user interface Serial1/0
ip target 192. 168. 12. only two 255. 255. 255. 0
simply no turn
!
user interface Serial1/1
ip target 192. 168. 12. only two 255. 255. 255. 0
simply no turn
!
router ospf 1
log-adjacency-changes
multilevel 0. 0. 0. 0 255. 255. 255. 255 region 0

R3
!
user interface Serial1/0
ip target 192. 168. 13. 3 255. 255. 255. 0
simply no turn
!
user interface Serial1/1
ip target 192. 168. 12. 3 255. 255. 255. 0
simply no turn
!
router ospf 1
log-adjacency-changes
multilevel 0. 0. 0. 0 255. 255. 255. 255 region 0


Which allows MPLS

When you have performed that your OSPF adjacencies needs to be working. Currently exactly what we must perform is actually implement the necessary MPLS demand permit MPLS on multilevel.


R1(config)#int se1/0
R1(config-if)#mpls ip
R1(config-if)#int se1/1
R1(config-if)#mpls ip

R2(config)#int se1/0
R2(config-if)#mpls ip
R2(config-if)#int se1/1
R2(config-if)#mpls ip

R3(config)#int se1/0
R3(config-if)#mpls ip
R3(config-if)#int se1/1
R3(config-if)#mpls ip


When you have applied your individual demand "mpls ip" for the the two attributes in the link, a great LDP adjacency are going to be formed and can show some sort of firewood shown under:


*Feb 21 years old apr: 15: 1951. 811: %SYS-5-CONFIG_I: Put together from unit by means of unit
*Feb 21 years old apr: 15: fifty two. 135: %LDP-5-NBRCHG: LDP Next door neighbor 192. 168. 13. 1: 0 (2) is actually UPWARDS


Consequently MPLS is actually permitted on the two attributes and the friends usually are interchanging name information. The actual LFIB, FIB and LIB are set up following the neighborships usually are formed.

Verifying MPLS Interfaces

Inorder to have that interfaces usually are mpls permitted your demand "show mpls interfaces" can be used. In business point out is actually "Yes" in the event the demand "mpls ip" is actually permitted for the user interface.


R3#sh mpls interfaces
Software IP Canal In business
Serial1/0 Sure (ldp) Absolutely no Sure
Serial1/1 Sure (ldp) Absolutely no Sure


Verifying LDP Neighbors

To find out your LDP friends employ "show mpls ldp neighbors". It will present your friends USERNAME that is founded on the greatest ip target in the mpls make it possible for user interface., your LDP neighborship uptime, that user interface it turned out observed and the ip handles in the MPLS permitted interfaces. Just like OSPF, LDP's political election in the USERNAME is actually initial decided on the greatest ip target in the loopback interfaces then your actual interfaces.



R3#sh mpls ldp neigh
Peer LDP Ident: 192. 168. 12. only two: 0; Community LDP Ident 192. 168. 12. 3: 0
TCP network: 192. 168. 12. only two. 646 - 192. 168. 12. 3. 46832
Point out: Oper; Msgs sent/rcvd: 18/18; Downstream
Upwards occasion: 00: 10: fifty nine
LDP breakthrough places:
Serial1/1, Src IP addr: 192. 168. 12. only two
Handles certain for you to peer LDP Ident:
192. 168. 12. only two 192. 168. 12. only two
Peer LDP Ident: 192. 168. 13. 1: 0; Community LDP Ident 192. 168. 12. 3: 0
TCP network: 192. 168. 13. 1. 646 - 192. 168. 12. 3. 26398
Point out: Oper; Msgs sent/rcvd: 6/6; Downstream
Upwards occasion: 00: 00: 39
LDP breakthrough places:
Serial1/0, Src IP addr: 192. 168. 13. 1
Handles certain for you to peer LDP Ident:
192. 168. 12. 1 192. 168. 13. 1




Let us configure loopbacks pertaining to R1, R2 and R3. Applying 1. 1. 1. 1, only two. only two. only two. only two and 3. 3. 3. 3 respectively and let us notice exactly what happends to the Peer LDP Ident.


R1#config capital t
R1(config)#int lo0
R1(config-if)#ip target 1. 1. 1. 1 255. 255. 255. 255

R2#config capital t
R2(config)#int lo0
R2(config-if)#ip target only two. only two. only two. only two 255. 255. 255. 255

R3#config capital t
R3(config)#int lo0
R3(config-if)#ip target 3. 3. 3. 3 255. 255. 255. 255


Following establishing, let us initial crystal clear your ospf practice for the routers. Make use of the "clear ip ospf process" and "clear mpls ldp neigbor" with make it possible for method. For some reason with Dynamips, you'll find simply no changes to the LDP ident and the OSPF router username, therefore its advisable to remove your OSPF practice initial and disabling initial MPLS for the interfaces after that renabling OSPF and MPLS. Currently let us notice what are the results to the LDP Ident.


R1#sh mpls ldp neigh
Peer LDP Ident: only two. only two. only two. only two: 0; Community LDP Ident 192. 168. 13. 1: 0
TCP network: only two. only two. only two. only two. 646 - 192. 168. 13. 1. 17752
Point out: Oper; Msgs sent/rcvd: 15/15; Downstream
Upwards occasion: 00: 05: twenty four
LDP breakthrough places:
Serial1/0, Src IP addr: 192. 168. 12. only two
Handles certain for you to peer LDP Ident:
192. 168. 12. only two 192. 168. 12. only two only two. only two. only two. only two
Peer LDP Ident: 3. 3. 3. 3: 0; Community LDP Ident 192. 168. 13. 1: 0
TCP network: 3. 3. 3. 3. 646 - 192. 168. 13. 1. 19721
Point out: Oper; Msgs sent/rcvd: 14/14; Downstream
Upwards occasion: 00: 05: twenty two
LDP breakthrough places:
Serial1/1, Src IP addr: 192. 168. 13. 3
Handles certain for you to peer LDP Ident:
192. 168. 13. 3 192. 168. 12. 3 3. 3. 3. 3


It can be today acquiring your loopback ip target as the Community Ident that proves which MPLS LDP chooses your USERNAME including precisely how OSPF will. You'll be able to personally power your LDP username by the demand "mpls ldp router-id loopback0 force" therefore it should take your ip target in the interfaces seeing that its USERNAME. On this case in point we people your loopback0 along with has already been your default USERNAME.

MPLS Product labels

Let us take a look how MPLS labels desired destination IP handles. When i mentioned in the beginning which MPLS creates some sort of name for several desired destination ip handles inside the redirecting table. If your labels usually are performed, the item propagates the information for you to its friends in order that they can understand what name they will placed on your package for the mailing router. An example with actuality, we can compare that for you to snail email running. The actual target for the letter will be the IP target and the Go program code will be the Label. The actual core mailbox is aware of best places to mail your letter, simply by thinking about your zero program code. Many people don't really need to see the whole target. Once the letter have been provided for your neighborhood mailbox, its the time these people see the whole target. The local mailbox is like your PE (Provider Edge) routers. This will be mentioned in the next submit.

To show your MPLS labels and precisely how the friends identify your path with their very own labels utilize "show mpls ldp bindings" demand.


R1#sh mpls ldp executed
tib access: 1. 1. 1. 1/32, rev 4
regional executed: tag: imp-null
remote control executed: tsr: only two. only two. only two. only two: 0, tag: 19
remote control executed: tsr: 3. 3. 3. 3: 0, tag: 20
tib access: only two. only two. only two. 2/32, rev 8
regional executed: tag: 19
remote control executed: tsr: only two. only two. only two. only two: 0, tag: imp-null
remote control executed: tsr: 3. 3. 3. 3: 0, tag: 21 years old
tib access: 3. 3. 3. 3/32, rev 10
regional executed: tag: 20
remote control executed: tsr: only two. only two. only two. only two: 0, tag: 21 years old
remote control executed: tsr: 3. 3. 3. 3: 0, tag: imp-null
tib access: 192. 168. 12. 0/24, rev only two
regional executed: tag: imp-null
remote control executed: tsr: only two. only two. only two. only two: 0, tag: imp-null
remote control executed: tsr: 3. 3. 3. 3: 0, tag: 19
tib access: 192. 168. 13. 0/24, rev 6
regional executed: tag: imp-null
remote control executed: tsr: only two. only two. only two. only two: 0, tag: 20
remote control executed: tsr: 3. 3. 3. 3: 0, tag: imp-null
tib access: 192. 168. 12. 0/24, rev 12
regional executed: tag: 21 years old
remote control executed: tsr: only two. only two. only two. only two: 0, tag: imp-null
remote control executed: tsr: 3. 3. 3. 3: 0, tag: imp-null


Investigate initial access mark with reddish. The actual TIB is also similar to LIB. Draw Facts Basic ended up being its old brand as soon as Label Transferring ended up being after that named Draw Transferring. 1. 1. 1. 1 will be the ip target access. Community executed suggests exactly what tag your router can put for the package for you to desired destination 1. 1. 1. 1 in line with the LIB the item earned. In this case we find it seeing that imp-null this means it doesn't put since that is a in your community came from. Out of the way Presenting suggests, your name your LDP neighbor router given to this particular subnet. TSR (Tag Transferring Router) only two. only two. only two. only two and that is router R2 assigns some sort of name of 19 seeing that identifier to this particular subnet and 3. 3. 3. 3 and that is router R3 assigns name 20 to this particular.

Let us take a look at the other access. For 2. only two. only two. only two, R1 has a tag of 19 to recognize that subnet however R2 offers imp-null since that arises from R2. Channels came from in your community to the router are never name. R3 pinpoints that seeing that name 21 years old.

MPLS LFIB

MPLS permitted routers don't name your packets before mailing determined by the LIB however in line with the LIB's of these friends learned by way of LDP. Many people name the item this way to ensure once the package extends to the neighbor, your neighbor is aware of accurately that name is designed for and tips on how to forward the item since that name information is actually from your router themselves. Examine your case in point under. I'll turn the link from R1 for you to R3 so the pacdkets definitely going pertaining to R3 can pass through R2. Why don't we additionally compare your LFIB before and following the final of inbound links.

Ahead of turn


Following Sealed



Take notice of the prefix 3. 3. 3. 3, as soon as R1 and R3 where specifically hooked up before When i turn off the link, your Outgoing tag or perhaps VC is actually Place tag. Consequently in case R1 receives some sort of package definitely going pertaining to R3, the item "pops" or perhaps takes away your name and will not exchange virtually any name since inside the LIB of R3, 3. 3. 3. 3 has a implicit-null. Following link have been turn off, your Outgoing tag or perhaps VC now's 21 years old. This kind of actually signifies that R1 ought to exchange some sort of name of 21 years old for you to packets definitely going pertaining to 3. 3. 3. 3. R2 with its LIB offers 21 years old pertaining to 3. 3. 3. 3. R2 for you to R3, should never be described since 3. 3. 3. 3 arises from R3. Let us look at your traceroute under pertaining to additional evidence.


R1#traceroute 3. 3. 3. 3

Form escape collection for you to abort.
Doing a trace for your option to 3. 3. 3. 3

1 192. 168. 12. only two [MPLS: Label 21 years old Exp 0] 88 msec 56 msec 59 msec
only two 192. 168. 12. 3 one hundred forty msec seventy six msec *


The first ut is actually from R1 for you to R2. You can view plainly who's described 21 years old. The other ut didn't show virtually any labels.

Verifying and Configuring Label Assortment

An easy demand for you to confirm your name assignment range is actually "show mpls name range". The number of labels can also be fixed to your loving by making use of "mpls name range minrange maxrange" demand.

Read More

IP Event Dampening

Nicely which was a feature i didnt recognize in any respect! And so in accordance with cisco file

"Interface condition alterations arise whenever interfaces usually are administratively brought up or maybe decrease or maybe if a great user interface alterations condition. As soon as a great user interface alterations condition or maybe flaps, course-plotting standards usually are alerted on the reputation on the avenues that will are influenced by the particular change throughout condition. Each user interface condition change needs just about all impacted equipment inside the network to help recalculate finest paths, put in or maybe get rid of avenues from the course-plotting dining tables, then publicise legitimate avenues to help peer routers. A good shaky user interface that will flaps excessively might cause some other equipment inside the network to eat considerable degrees of system running means and also bring about course-plotting standards to forfeit synchronization with the condition on the flapping user interface. inches

http: //www. cisco. com/en/US/docs/ios/12_0s/feature/guide/s_ipevdp. html#wp1027129

Ip celebration dampening we can configure timers that will dampen the particular user interface so getting rid of the idea from the course-plotting process until the user interface is usually dependable once again.

These kind of timers usually are:

Restrain tolerance -- As soon as a great int goes up and down it's given a penalty value, the ideal penalty charges make fish an int is usually permitted to subject to is usually that timer, once the value is usually arrived at user interface is defined throughout dampen condition

50 percent time period -- whenever a great user interface halts flapping the particular penalty is usually reduced through fifty percent after each and every period of time of this value is usually put together.

Recycle tolerance -- once the option is just about to become disseminated once again inside the network is usually allowed as long as the particular reuse tolerance remains a confident value. Beliefs cover anything from 1 to help 20k, default is usually 1000

Maximum restrain time -- This is actually the utmost period of time a great user interface can certainly stay dampened

This illustration configures user interface dampening on Ethernet user interface 0/1 and also pieces the particular fifty percent lifestyle to help 40 moments, the particular reuse tolerance to help 2000, the particular restrain tolerance to help 15000; and the utmost restrain time and energy to 100 moments:

user interface Ethernet 0/1

dampening 40 1000 10000 100

R4#show interfaces ethernet 0/1 dampening
Ethernet0/1
Flaps Charge Supp ReuseTm HalfL ReuseV SuppV MaxSTm MaxP Reboot
0 0 BOGUS 0 40 1000 10000 100 10078 0
R4#

Read More

How Multi is MP-BGP in IOS-XR

 When two years ago i was writing the first part of "How Multi is MP-BGP in IOS-XR", i concluded with the following:

    In IOS-XR you need an IPv6 NH in order to activate the IPv6 AF for an IPv4 BGP session.
    If you don't have an IPv6 NH, then the IPv4 BGP session won't even come up.
    The above was done to protect against misconfiguration, because otherwise you would get a misleading v4 mapped v6 address as NH.
    If you have an IPv6 NH, then the IPv4 BGP session with the IPv6 AF will come up.
    If afterwards you remove the IPv6 NH, then the session deliberately remains up and you get a misleading v4 mapped v6 address as NH.

Although back then i didn't agree with the above behavior, i couldn't do anything more than just accept the "solution" given: print a warning message if such a case is met.

Recently i realized that the same IOS-XR developers decided to bring even more confusion into the engineer's everyday job.

Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes
New Fact: You must display an IPv4 address as next-hop for IPv6 prefixes

I probably need to explain it a little bit more, because i'm talking about 6VPE this time. 6VPE is a technology/architecture which allows you to have IPv6 connectivity over an IPv4 MPLS (and not only) network.

The original 6VPE scenario where i met this behavior is quite complex, but for simplicity let's assume that it includes only the following:

2 x CE routers (CE1, CE2)
2 x 6VPE routers (PE1, PE2)
2 x P/RR routers (P1, P2)

This is a very simple VPN topology (with only two sites) like the following:

CE1 <=> PE1 <=> P1 <=> P2 <=> PE2 <=> CE2

All routers are exchanging IPv4/IPv6 prefixes using BGP, in order to have IPv4/IPv6 connectivity between the two CEs. IPJ describes the relevant route advertisement with a very nice picture:









If we could follow the exchange of information between some of these routers, then we would notice something like the following.

CE1 sends its IPv6 prefixes to PE1 through MP-BGP and PE1 sends them to P1 accordingly. Since (as of now) there is no support for LDP over IPv6, PE1 sends the IPv6 prefixes using a v4-mapped IPv6 address as next-hop (that's encoded inside the NLRI as shown in the debugs).

This is how the IPv6 prefix is sent from PE1 (10.10.253.164) to P1 (10.10.253.161).

PE1#sh bgp vpnv6 unicast all neighbors 10.10.253.161 advertised-routes
BGP table version is 7, local router ID is 10.10.253.164
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:109 (default for vrf TEST-VRF)

*> 2001:DB8:2:60::22/127
                    2001:DB8:2:50::23        0         32768 ?



This is the relevant debug info that shows how exactly the IPv6 prefix (2001:DB8:2:60::22/127 with next-hop of ::FFFF:10.10.253.164) is sent from PE1 to P1.

BGP(5): (base) 10.10.253.161 send UPDATE (format) [100:109]2001:DB8:2:60::22/127, next ::FFFF:10.10.253.164, label 2689, metric 0, path Local, extended community RT:100:109



And this is how the IPv6 prefix is shown on the P1 (10.10.253.161) when received from PE1 (10.10.253.164):

P1#sh bgp vpnv6 unicast neighbors 10.10.253.164 routes
BGP router identifier 10.10.253.161, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 3888712472
BGP main routing table version 3
BGP NSR Initial initsync version 3 (Reached)
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:109
*>i2001:DB8:2:60::22/127
                      10.10.253.164           0    100      0 ?


Now, if the old fact was existent in the case of VPNv6 prefixes as in the case of simple IPv6 prefixes, then the IPv6 BGP session shouldn't even come up. Instead, it comes up and works fine. But, in order to confuse me even more, the next-hop of an IPv6 prefix is an IPv4 address (!!!).

Reminder...
Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes

Quoting from RFC 4659 (BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN):

When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:

- whose 8-octet RD is set to zero, and

- whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6  address [V6ADDR] containing the IPv4 address of the advertising BGP speaker. This IPv4 address must be routable by the other BGP Speaker.


Now, if we check the PE2 on the other side, who is also getting some IPv6 prefixes from CE2, we'll notice that everything is fine and according to everything we know about 6VPE. So this time the IPv6 prefixes have a v4-mapped IPv6 address as next-hop, which is the expected output for a 6VPE topology.

This is how an IPv6 prefix is shown on the P2 (10.10.231.4) when received from PE2 (10.10.253.165):

P2#sh bgp vpnv6 unicast all neighbors 10.10.253.165 routes
BGP table version is 4, local router ID is 10.10.231.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:141
*>i2001:DB8:10:1::22/127
                    ::FFFF:10.10.253.165
                                             0    100      0 65141 ?


Let's summarize:

P1: IPv6 prefix 2001:DB8:2:60::22/127 with 10.10.253.164 as NH
P2: IPv6 prefix 2001:DB8:10:1::22/127 with ::FFFF:10.10.253.165 as NH

If you still haven't figured out the difference between P1 and P2 based on the outputs given, let me tell you that P1 is an IOS-XR (4.2.x) based platform while P2 is an IOS (15.x) based one. In terms of functionality everything works fine, because internally IOS-XR uses the correct v4-mapped IPv6 address as next-hop. It just doesn't display it on the CLI, neither on the debugs.

Now you might wonder why such a difference in IOS-XR behavior. After waiting for several weeks for a lab reproduction from Cisco, because nobody knew about this behavior, i got a very enlightening answer from the developers:

IOS-XR decided it's best to display the actual next hop which is a v4 nexthop and is also registered with the v4 RIB for tracking purposes, rather than what is transported in the NLRI and matches the output of everything else. So the behaviour is indeed expected and works 'by design'.

Reminder...
Old Fact: You can't have an IPv4 address as next-hop for IPv6 prefixes

Don't you love those guys? First they tell that you can't have a v4 nexthop, but now they tell you that it's better to display a v4 nexthop, although the actual NLRI has a different one.

Luckily, someone inside Cisco (thx Xander once more) agreed that this behavior is misleading, so an enhancement request (CSCuj74543) was opened. If you would like to change this behavior too, please link your case to this DDTS. At the same time a documentation DDTS (CSCuj76745) was opened in order to officially describe this IOS-XR "expected" and "by design" behavior on CCO.

Read More

IP Phone Trust and CoS Extend

- ports are configured to trust the QoS marking only if the presence of a Cisco IP Phone is
sensed via CDP messages.

- If no Cisco device is detected on the port then the QoS markings are not trusted, even if the port is configured for trust.
- the switch may also instruct the IP Phone’s switch to apply specific CoS markings for frames received from the connected PC. The switch may either accept (trust) 802.1p bits received from the attached PC or enforce the instructed value. This feature particularly
makes sense to be used with the dot1p Voice VLAN option.

config-set:

interface FastEthernet0/6
mls qos trust cos
mls qos trust device cisco-phone
switchport priority extend cos 1


verification:

show mls qos interface #

Read More

Debugging IPv6 MTU issues in Windows

 
A common problem you might face soon (World IPv6 Day is 5 days away) is reachability to IPv6 sites due to MTU issues. ICMPv6 has a nice internal mechanism which is supposed to help the application overcome these issues, but like in the IPv4 world, not everything is perfect.

Let's suppose that an IPv6 subscriber is using a DSL router and is connected through PPPoE to a BRAS.

TARGET <=> BRAS <=> DSL-ROUTER <=> HOST

The usual MTU for PPPoE connections is 1492 bytes, as shown below.

1500 bytes = Ethernet Payload
-     6 bytes = PPPoE header
-     2 bytes = PPP ID
---------------------------------
1492 bytes = IPv6 Packet that can be carried over a PPPoE connection

If your host is configured with 1492 (or something lower) as MTU on its LAN interface, then the OS running on it will automatically take care of "fragmentation", so you don't need to worry for anything. Unfortunately this isn't a common scenario by default. You either have to configure it manually on the host or if you are lucky enough and the DSL modem supports advertisement of MTU to its LAN interface through RA messages (and your host accepts them), it will happen automatically.

If your host is configured with anything larger than 1492 on its LAN interface (in most cases it's the default of 1500), problems might arise.

Users with hosts running Windows can try to ping an IPv6 address (i.e. the next hop after the DSL router) in order to find possible issues with the MTU. The closer the target is, the easier it will be to troubleshoot the problem. Then you start moving towards the target until you meet the issue.

First, some numbers you will need regarding the various headers

1492 bytes = IPv6 Packet
-  40 bytes = IPv6 Header
-   8 bytes = ICMPv6 Header
-------------------------------
1444 bytes = ICMPv6 payload data

Since Windows ping uses the actual payload as a size, if you want to send a total of 1492 bytes, you have to send 1492-40-8=1444 bytes of ICMPv6 payload data. Anything larger will lead to either a problem or to fragmentation.

Windows>ping -l 1444 x:x::x

Pinging target [x:x:xx] with 1444 bytes of data:

Reply from x:x:xx: time=53ms
Reply from x:x:xx: time=51ms
Reply from x:x:xx: time=54ms
Reply from x:x:xx: time=53ms

Ping statistics for x:x:xx:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 51ms, Maximum = 54ms, Average = 52ms

These are the relevant Wireshark captures.

Read More

3550 & 3560 QoS

3550
fastethernet
QOS scheduling: tx-(4q0t),tx-(1p3q0t)

gigabitethernet
QOS scheduling: tx-(4q2t),tx-(1p3q2t)

- priority at queue 4
- default port cos 0
- default port is untrusted
- default cos to tx queue mapping
0 - 1
1 - 1
2 - 2
3 - 2
4 - 3
5 - 3
6 - 4
7 - 4

- default cos-dscp map

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

- default wrr weights
wrr bandwidth weights:
qid-weights
1 - 25
2 - 25
3 - 25
4 - 25

weight 4 range (0-255) when set to "0" it is configured as expedite queue

3560
QoS scheduling: tx-(4q2t)
-same cos-tx queues mapping
-same cos-dscp mapping
- same queue bandwidth weights
-no vlan-based classification
- can use class based marking to set dscp



to verify queing

show mls qos interface queueing

to change cos-dscp mapping:

mls qos map cos-dscp (dscp-values)


config-set for 3550 setting cos-tx queues mapping:

Rack1SW3(config-if)#wrr-queue cos-map 1 0 1 2
Rack1SW3(config-if)#wrr-queue cos-map 2 3
Rack1SW3(config-if)#wrr-queue cos-map 3 4
Rack1SW3(config-if)#wrr-queue cos-map 4 5
Rack1SW3(config-if)#priority-queue out ---configure priority queueing

Rack1SW3#show mls qos interface queueing
FastEthernet0/1
QoS is disabled. Only one queue is used
When QoS is enabled, following settings will be applied
Egress expedite queue: dis
wrr bandwidth weights:
qid-weights
1 - 25
2 - 25
3 - 25
4 - 25
Cos-queue map:
cos-qid
0 - 1
1 - 1
2 - 1
3 - 2
4 - 3
5 - 4
6 - 4

ex:

wrr-queue bandwidth 1 2 3 4

10%- queue1
20%-queue2
30%-queue3
40%-queue4

Read More

Flex Links

Flex Links feature is used as an alternative to Spanning-Tree Protocol in
environments where physical loops occur in the layer 2 network
- The backup link operates in standby mode, and waits for the line protocol of the active link to go down. If the line protocol of the active link is down, the backup link becomes active and immediately starts forwarding. When the active link’s line protocol status comes back up, the backup link goes back into standby state and stops forwarding traffic.


SW1:

interface Port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport backup interface Fa0/16
switchport backup interface Fa0/16 preemption mode forced
switchport backup interface Fa0/16 preemption delay 20
!
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/16
switchport trunk encapsulation dot1q
switchport mode trunk

SW2:

interface Port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
interface FastEthernet0/16
switchport trunk encapsulation dot1q
switchport mode trunk

SW3:

interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/16
switchport trunk encapsulation dot1q
switchport mode trunk


verification:

SW1#show interfaces po1 switchport backup
Switch Backup Interface Pairs:
Active Interface Backup Interface State
------------------------------------------------------------------------
Port-channel1 FastEthernet0/16 Active Up/Backup Standby

Read More

Frame Relay Fragmentation and Interleaving with MLPPP

1) MLPPP uses fragmentation scheme where large packets are sliced in pieces and sequence numbers are added using special MLPPP headers
2) Small voice packets are interleaved with fragments of large packets using a special priority queue

We see that MLPPP was originally designed to work with multiple physical links at the same time. However, PPP Multilink Interleave only works with one physical link. The reason is that voice (small) packets are being sent without sequence numbers. If we were using multiple physical links, the receiving side may start accepting voice packets out of their original order (due to different physical link latencies). And since voice packets bear no fragmentation headers, there is no way to reorder them. In effect, packets may arrive to their final destination out of order, degrading voice quality.

To overcome this obstacle, Multiclass Multilink PPP (MCMLPPP or MCMLP) has been introduced in RFC 2886. Under this RFC, different “fragment streams” or classes are supported at sending and receiving sides, using independent sequence numbers. Therefore, with MCMLPPP voice packets may be sent using MLPPP header with separate sequence numbers space. In result, MCMPPP permits the use of fragmentation and interleaving over multiple physical links at time.

Now back to our MLPPPoFR example. Let’s imagine the situation where we have two routers (R1 and R2) connected via FR cloud, with physical ports clocked at 512Kpbs and PVC CIR values equal to 384Kbps (There is no ATM interworking in this example). We need to provide priority treatment to voice packets and enable PPP Multilink and Interleave to decrease serialization delays.

Topology:

[R1]---[DLCI 112]---[Frame-Relay]---[DLCI 211]---[R2] 

Qos Policy:R1

class-map match-all VOICE
 match ip dscp ef 
class-map match-all SIGNALING
 match ip dscp cs3 
!
!
policy-map CBWFQ
 class VOICE
  priority 48
 class SIGNALING
  bandwidth 8
 class class-default
  fair-queue

 Next create a Virtual-Template interface for PPPoFR. We need to 
calculate the fragment size for MLPPP. Since physical port speed is 
512Kpbs, and required serialization delay should not exceed 10ms 
(remember, fragment size is based on physical port speed!), the fragment
 size must be set to [512000/8]*0.01=640 bytes. How is the fragment size 
configured with MLPPP? By using command ppp multilink fragment delay
 – however, IOS CLI takes this delay value (in milliseconds) and 
multiplies it by configured interface (virtual-template) bandwidth (in 
our case 384Kbps). We can actually change the virtual-template bandwidth
 to match the physical interface speed, but this would affect the CBWFQ 
weights! Therefore, we take the virtual-template bandwidth (384Kpbs) and
 adjust the delay to make sure the fragment size matches the physical 
interace rate is 512Kpbs. This way, the “effective” delay value would be
 set to “640*8/384 = 13ms” (Fragment_Size/CIR*8) to accomodate the 
physical and logical bandwidth discrepancy. (This may be unimportant if 
our physical port speed does not differ much from PVC CIR. However, if 
you have say PVC  CIR=384Kbps and port speed 768Kbps you may want to pay
 attention to this issue)

R1:

interface Loopback0
 ip address 177.1.101.1 255.255.255.255
!
interface Virtual-Template1
 bandwidth 384
 ip unnumbered Loopback0
 ppp multilink
 ppp multilink fragment delay 13
 ppp multilink interleave
 service-policy output CBWFQ

R2:

interface Loopback0
 ip address 177.1.102.1 255.255.255.255
!
interface Virtual-Template1
 bandwidth 384
 ip unnumbered Loopback0
 ppp multilink
 ppp multilink fragment delay 13
 ppp multilink interleave
 service-policy output CBWFQ

Next we configure PVC shaping settings by using legacy FRTS configuration. Note that Bc is set to CIR*10ms.

R1&R2

map-class frame-relay SHAPE_384K
 frame-relay cir 384000
 frame-relay bc 3840
 frame-relay be 0
 frame-relay mincir 384000

apply all the settings to the Frame-Relay interfaces:

R1:

interface Serial0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 112 ppp Virtual-Template1
  class SHAPE_384K

R2:

interface Serial0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 211 ppp Virtual-Template1
  class SHAPE_384K

Verification

R1#SHOW INT VIRtual-ACCess 2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback0 (177.1.101.1)
  MTU 1500 bytes, BW 384 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Link is a member of Multilink bundle Virtual-Access3
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to Serial0/0.1 DLCI 112, Cloned from Virtual-Template1, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:05, output never, output hang never
  Last clearing of "show interface" counters 00:48:42
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     572 packets input, 10084 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     572 packets output, 8960 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
R1#
R1#
R1#SHOW INT VIRtual-ACCess 3
Virtual-Access3 is up, line protocol is up
  Hardware is Virtual Access interface
  Interface is unnumbered. Using address of Loopback0 (177.1.101.1)
  MTU 1500 bytes, BW 384 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Open: IPCP
  MLP Bundle vaccess, cloned from Virtual-Template1
  Vaccess status 0x40, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:37:26, output never, output hang never
  Last clearing of "show interface" counters 00:47:35
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/128 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 232 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     12 packets input, 1068 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     12 packets output, 1134 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
R1#
R1#show policy-map inte
R1#show policy-map interface
 Virtual-Template1

  Service-policy output: CBWFQ

    Service policy content is displayed
                    for cloned interfaces only such as vaccess and
                    sessions
 Virtual-Access3

  Service-policy output: CBWFQ

    Class-map: VOICE (match-all)
      5 packets, 510 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
      Queueing
        Strict Priority
        Output Queue: Conversation 136
        Bandwidth 48 (kbps) Burst 1200 (Bytes)
        (pkts matched/bytes matched) 5/510
        (total drops/bytes drops) 0/0

    Class-map: SIGNALING (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs3 (24)
      Queueing
        Output Queue: Conversation 137
        Bandwidth 8 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
      7 packets, 534 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 128
        (total queued/total drops/no-buffer drops) 0/0/0

R1# show ppp multilink 

Virtual-Access3, bundle name is R2
  Endpoint discriminator is R2
  Bundle up for 00:49:28, total bandwidth 384, load 1/255
  Receive buffer limit 12192 bytes, frag timeout 1000 ms
  Interleaving enabled
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x7 received sequence, 0x7 sent sequence
  Member links: 1 (max not set, min not set)
    Vi2, since 00:49:28, 624 weight, 614 frag size
No inactive multilink interfaces
R1#
R1#
R1#
R1#sho int s0/0
Serial0/0 is up, line protocol is up 
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  298, LMI stat recvd 299, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 49/0, interface broadcasts 0
  Last input 00:00:05, output 00:00:02, output hang never
  Last clearing of "show interface" counters 00:50:43
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: dual fifo
  Output queue: high size/max/dropped 0/256/0
  Output queue: 0/128 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     947 packets input, 31366 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     946 packets output, 31062 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up 

Read More

FRF.12 Link Fragmentation and Interleaving calculation

Assuming we want to configure FRF.12 with interleaving and fragmentation delay of 10ms on a 768Kbps link:

Delay = Frame size (bits) / Link Bandwidth (bps)
0.01s = Frame size (bits) / 768,000 bps
Frame size = 7680 bits = 960 bytes

This is the configuration example extracted from the AutoQoS applied on the frame relay sub-interface

map-class frame-relay AutoQoS-FR-Se0/0/0:1-202

  frame-relay cir 768000

  frame-relay bc 7680

  frame-relay be 0

  frame-relay mincir 768000

  frame-relay fragment 960

  service-policy output AutoQoS-Policy-Trust

Read More