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

Introduction to FCoE

• SCSI protocol: carried over a network transport via serial implementation. Two primary transports today, FC and IP.
• Fibre Channel provides high-speed transport for SCSI payload via HBA. FC overcomes many shortcomings of parallel I/O and combines best attributes of a channel and a network together.
• Storage Protocol Technologies:
• FCP
• iSCSI
•  FC has many similarities to IP (TCP). FC is hop-by-hop flow controlled. No end-to-end flow control at FC level only at SCSI level. To maintain no drop packets. SCSI has timeout of 60s. You can imagine if you drop one packet, scsi operation gets corrupted and then transmits, no rapid retransmission.
• can run a lot of parallel connections.
• E_port: expansion port, ISL
• TE_port: 802.1q, ability to run multiple VSAN, trunking for VSANs
• N_Port: Node Port, server, HBA etc…they connect to F_port on the switch.
• NP_Port: It goes in an NPV mode switch, a switch that emulates a host or proxy. Emulates an N port, reduces a lot of management.
• WWN: burnt-in unique addresses assigned to fabric switches, ports, and nodes by manufacturer. That’s where the similarity ends with comparison to MAC addresses. FC packets, WWN is not there, only used in a few frames to uniquely identify the sender of that packet. Otherwise you’d see in the src/dst is a dynamic address (FC_ID). They’re unique and registered with IEEE.
• FC uses something similar to DHCP. It’s called FCID. Divided into “switch domain” (8bits), “Area (8bits)” and “Device” (8bits). Makes routing decision easy with it. Switch Topology Model. Switches assign FC_ID addresses to N_Ports.
• 32K Exchange frames,8K chunks is sequence and each of those 8K chunks is made of 2K frames. FC-2 Hierarchy. Makes it easy to fire multiple IO because each one has unique OX_ID (exchange ID) so we can load balance them on ISL
• Cisco is the only vendor that supports FC portchannels. Trunking capability, really allows Cisco differentiation.
• VSANs. Same reason we have VLANs, we have VSANs. Shared services that are running in FC environment, in order to reduce, we use VSAN.
• Used for storage tiering. 5K, 7K and UCS have this as well as MDS.
• Initiator has HBA. East-West seperation.
• Fabric Shortest Path First: Just like OSPF. FSPF routes traffic based on destination domain ID.
• Storage Security, major activity done daily. Zones are bi-dir ACL. Use WWN for ACL, so use those for the ACL. Fabric in hardware enforces who the initiator communicates with. Zone members can only see and talk to other members of the zone. Zones belong to a zoneset. Zoneset must be “active” to enforce zoning. Only one active zoneset per fabric or per VSAN.
• When you first physically join the fabric and negotiate speed, the initiator will do a FLOGI, it’ll start sending packets to the switch (not target). Tell it, I’m an initiator and I need to register to Name Server and I need to tell it what my WWN is, it’s going to grant me a FCID. Now I have an address that I can use to send frames out there. Src/Dst is FCID and NOT WWN.
• Talk to FC switch and figure out what devices I can communicate to, and FC db will determine from zone devices it can talk to. Then it does a P_LOGI which will do end to end communication. PLOGI is done end to end. Target would do the same steps as initiator at the same time.
• What is NPIV? Before we do NPV, we need to understand NPIV. N-Port ID Virtualization. Allows to allocate multiple FCIDs to a single port. Feature on core director. If we have a VMware server, we can assign a FCID to each different VMs, which allows tracking them differently for each fabric.
• Then what is NPV? Think of a 5K with 2K and lots of end devices. NPV mode allows to turn that switch into an initiator or into a host. So don’t have to run shared services, no ISL b/w MDS or NPIV switch. It logs as an N_Port rather than as an E_Port. It’s proxying all of the real-servers that are plugged into it. In TOR design, you have hundreds of UCS and 5K, going into my MDS…you can really reduce that by using NPV mode in TOR switches. Use with NPIV core directors, could be an MDS or 7K.

Advancements in Ethernet:

• adoption for 10G is a major driver. Ramping to 40GE. Puts a nail in the coffin of native FC speeds. Better than 8G or 4G FC since every DC now has 10G. Once 10G to the server happens, it’ll put a nail in the coffin for FC, since FC requires a PCI card which is power hungry device.
• Standards for FCoE: FC is made up of T11 (FC-BB-5, FC on other network media) standard and IEEE 802.1 DCB. DCB includes, PFC [Lossless ethernet-802.1Qbb] + ETS[prority grouping, 802.1Qaz] + DCBX[configuration verification, 802.1Qaz]
• PFC:Priority Flow Control (802.1Qbb), available on 5k, 2k, 7k, MDS. Able to pause FCoE traffic. Ability to accept pause frames.
• ETS: Enhanced Transmission selection: allows ability to create groups of protocol and bandwidth to protocol. I want to reserve 80% on the wire for FCoE traffic and rest for Ethernet. Down at L2.
• DCBX: 802.1Qaz, going to go through the DCBX process, that they support PFC, ETC and FCoE before they send out FCoE packet.
• It is a standard. They are all technically stable. term used by standing committee that it has passed a milestone of standards and vendors can start making products. So FCoE is a standard now.
• You can use twinax cable for FCoE. SFP+ CX-1 Copper (SFF 8431). Drives down the power and cost significantly. <10m. Only 0.1W per port. Cable and SFP are physically one component.
• CNA: HBAs that enable both FCoE and LAN traffic out of the same port. Single chip. FCoE in software can also be done with the software driver. You can run FCoE on intel or broadcom chip.

FCoE Technology/Unified Fabric:

• completely based on the FC model. WWNs, FC-IDs, Zoning, Nameserver, RSCN. Compare this with iSCSI, completely different model than FC. Very different management and tools.
• yet another overlay network.
• Products, 2k, 5k, N7K (32 port F-series), MDS 9500 (8-port FCoE card)
• FCoE is two different protocols: FCoE itself and FIP (FCoE initialization Protocol)–> control plane protocol.
• FIP is fairly shortlived protocol. It does VLAN Discovery, FCF discovery (fibre channel forwarder…fc switch inside of a ethernet switch), FLOGI/FDISC..need to login and get FCID and will be using that inside my FC packets. FIP will complete and will hand it off to FC.
• 2180 byte frame (baby jumbo frame in ethernet environment).

Read More

IP Services: Syslog, WCCP, ICMP

SYSLOG:

• uses UDP port 514
• use, logging <host> command and optionally, logging trap.
• default facility of local7
• e.g: “service timestamps log datetime localtime” à logging 192.168.1.100 à logging monitor informational.

 WCCP:

· uses UDP port 2048

· upto 32 content engines can communicate with a single router using WCCPv1.

· The content engine with the LOWEST IP address is elected as the lead engine.

· WCCPv1, only ONE router can redirect traffic to a content engine or cluster of content engines. ONLY supports HTTP traffic (TCP port 80)

· WCCPv2, multiple routers and multiple content engines can be configured.

§ Supports TCP and UPD traffic other than port 80, including, FTP caching, FTP proxy, web caching for non 80 ports, real audio, video and telephony.

§ supports multicast.

§ provides MD5 security “ip wccp password password”

§ load distribution

§ transparent error handling.

§ default version is WCCPv2.

· Configuring

§ globally: ip wccp web-cache group-address <ip> password Cisco

§ redirecting traffic out: ip wccp web-cache redirect out ß to content engine

§ inbound traffic on interface is excluded from redirection: ip wccp redirect exclude in

ICMP:

· Echo Request: sent by a ping from the host to test node reachability

· Echo Reply: Indicates the node can be reached successfully.

· Redirect: sent by the router to the source host to stimulate more efficient routing

· Time Exceeded: sent by the router if an IP packet’s TTL filed reaches zero.

Read More

IP Services: SNMP, NTP

NTP:

• NTP server: (global) ntp master 7 ß stratum 7
• NTP symmetric active mode: router/switch mutually synchronizes with another NTP host, configured with ntp peer command. (global) ntp peer 10.1.1.1
• NTP broadcast client: Listens to NTP broadcasts on the Ethernet. (int) ntp broadcast client
• NTP client: configures, “ntp server 10.1.1.1”
• Authentication on NTP:
  • ntp authentication-key 1 md5 <name>
  • ntp authenticate
  • ntp trusted-key 1
• under interface configure “ntp broadcast” (broadcast the time)
• show ntp associations

 SNMP

• SNMPv1: simple authentication with communities, used MIB-I
• SNMPv2: removed requirement for communities, added GetBulk and inform messages, MIB-II
• SNMPv2c: only difference, allowed SNMPv1 style communities with SNMPv2
• SNMPv3: better security, backward compatibility to communities.
• communities: read-only, read-write, trap.
• Inform requests are acknowledged with an SNMP response packet.
• Messages:
  • Response: responds to information in Get and Set requests.
  • Inform: A message used b/w SNMP managers to allow MIB data to be exchanged about agents they both manage.
• MIBS:
  • RMON is outside MIB-II
• SNMPv3 adds authentication and encryption. MD5 and SHA creates a message digest for each protocol message (authentication) and DES to encrypt messages providing encryption (privacy).
• SNMP embedded event manager
  • automatic recovery actions are performed without need to fully reboot the routing device
  • allows event management capability directly inside the Cisco IOS devices.
  • action snmp-trap enables the traps event-manager command, also requires snmp-server configuration.
  • two types of EEM policy: applets and script
  • E.g: event manager applet IOSWD_Sample1
    • event ioswdsysmon sub1 cpu-proc taskname “task 1” op ge val 25 period 10 (triggers an applet when avg cpu usage is greater than or equat to 25% for 10 seconds. )
    • action 1.0 syslog msg “IOSWD_Sample1 Policy Triggered” (generates syslog notification)

Read More

CCIE: Routing To Next-hop vs Routing To Interface

Concept learnt from IE’s Vol5.0 workbook for “IP Routing”
 

When routing to a next-hop value the router performs L2 to L3 resolution on the next-hop address. (e.g. ip route 150.1.4.4 255.255.255.255 155.1.146.4). So in the arp table, you’ll see the MAC for ip address: 155.1.146.4.

• When routing to an INTERFACE, the router performs L2 to L3 resolution on the FINAL destination (not on the next hop). (e.g. ip route 150.1.6.6 255.255.255.255 fa0/0 configured on Router1). Let’s assume 150.1.6.6 is a Loopback interface on Router6 and Router 6 is connected to the LAN via Fa0/6. When we configure the ip route mentioned above on R1, on R1′s ARP table, you’ll see the MAC address of Fa0/6 interface for the loopback of R6 (i.e. 150.1.6.6). This is because, PROXY ARP is enabled by default on the routers. If we were to disable proxy arp on Fa0/6, you’d notice that you won’t be able to ping the loopback of R6 anymore, since the router does not know the correct l2 address to use when building the L2 frame. You’ll see “encapsulation failed” message in the debugs:

*Mar  5 02:18:49.733: IP ARP: creating incomplete entry for IP address: 150.1.6.6 interface FastEthernet0/0
*Mar  5 02:18:49.733: IP ARP: sent req src 155.1.146.1 000f.f756.6560,
                 dst 150.1.6.6 0000.0000.0000 FastEthernet0/0
*Mar  5 02:18:49.733: IP: s=155.1.146.1 (local), d=150.1.6.6 (FastEthernet0/0), len 100, encapsulation failed.

• Resolution: 1) change the ip routing so it uses next hop rather than ARPing on Final destination. 2)statically configure the MAC address to use when sending packet to the loopback of R6 by using: router(config)”arp 150.1.6.6 <mac> arpa command.

Read More

An Introduction To IP Multicast

All hosts that are connected to a LAN must use a standard method to calculate a L2 multicast address from the L3 multicast address and assign it to their NICs.

IGMP provides communication b/w hosts and a router connected to the same subnet. CGMP = IGMP snooping helps switches learn which hosts have requested to receive the traffic for a specific multicast application. (switches learn which ports would like to receive Mcast traffic using CGMP)

Some Multicast routing protocols (allows routers to forward multicast traffic from MCast servers to hosts. Distance Vector Multicast Routing Protocol (DVMRP), Multicast OSPF (MOSPF), and PIM-DM and PIM-SM.

Multicast is UDP-based (unreliable). Some multicast protocol mechanisms occasionally generate duplicate packets and deliver packets out of order.
   
The first 4 bits of the first octet for a class D address are always 1110.
    Range: 224.0.0.0 to 239.255.255.255 ( no need for masks), only one requirement, first 4 bits have to be 1110.
    Permanent multicast groups: 224.0.0.0 – 224.0.1.255
        for non-routing purposes: 224.0.0.0 224.0.0.255 (e.g. 224.0.0.1 [all multicast capable hosts on a local network] and 224.0.0.3 [all multicast-capable routers on local network]). 224.0.0.4 (DVMRP routers)
        for when packets need to be routed: 224.0.1.39 (RP announce) – 224.0.1.40 (RP discovery) (used by Auto-RP).
    Used with Source-Specific Multicast (SSM), 232.0.0.0 – 232.255.255.255
        purpose of these applications, to allow a host to select a source for the multicast group. Helps make Mcast routing efficient, allows a host to select a better-quality source and helps network admins minimize DoS attacks. ONLY IGMPv3 capable hosts can use this feature.
    GLOP: 233.0.0.0 – 233.255.255.255
        can be used by anyone who owns a registered ASN to create 256 global multicast addresses. Uses the value 233 in first octet and the ASN in the second and third octet. E.g: ASN 5663 would convert to: 0001011000011111. First eight bits equal to 22 and last 8 bits equal to 31, will become, 233.22.31.0 to 233.22.31.255
    Private: 239.0.0.0 – 239.255.255.255
    Multicast addresses for “transient” group: remaining multicast addresses are transient groups. Enterprise is expected to release this after use.
    Mapping IP Multicast addresses to MAC addresses:
        e.g 228.10.24.5, replace the first 4 bits 1110 à 01-00-5E (first 6 hex of 12 hex)
        replace next 5 bits of binary IP with 0 ALWAYS
        01-00-5E-0 (becomes now)
        the last 23 bits of binary IP in the last 23 bit space of the multicast MAC address.
        A-18-05
        0×01-00-5E-0A-18-05
        possibility of duplicate addresses is there!!
    Three different tools, namely CGMP, IGMP snooping and RGMP allow switches to optimize their multicast forwarding logic by answering the question of which hosts to forward traffic to in a broadcast domain.
    IGMP:
        IGMP messages are sent in IP datagrams with IP protocol number2, IP TTL set to 1.
        IGMP packets pass only over a LAN and not forwarded by routers due to TTL.
        2 Goals: to inform mcast router that a host wants to receive packets from a specific group and to inform local multicast routers that a host wants to leave a mcast group.
        IGMP, b/w hosts and router.
        IGMP v2 packet:
            Type (8 bit) has four message types: Membership query, version 1 membership report (for backward compatibility), Version 2 Membership report, Leave Group.
            Max response time: default 100 (10 seconds) default. Allows for tuning response time for the Host Membership Report.
            checksum
            Group Address: set to 0.0.0.0 in general query and to group address in Group specific query.
        REASONS for v2: better “Leave” mechanism to shorten the leave latency. Group-specific query messages permit router to send a query for a specific group instead of all groups. Provides MRT field. Querier election process: provides the method for selecting the preferred router for sending Query messages when multiple routers are connected to the same subnet.
            IGMP v2 router sends IGMPv2 quey message every 125 seconds.
        Multicast hosts must listen to the well-known 224.0.0.1 multicast group address to participate in IGMP and to receive mcast queries.
        by setting the group address to be 0.0.0.0 the router is asking, “does anyone want to receive multicast traffic for any group?” Host responds with the IGMP report messages to inform Router.
        Host sends, “solicited host membership report” and “unsolicited host membership report”
        Multicast router only needs 1 report to forward traffic out its interface whether there are 1 or 200 users.
        IGMPv2 uses, MRT timer to suppress many of the unnecessary IGMP reports. Timer is called “query response interval”. Report suppression is when a host receives a report sent by another host for the same mcast group for which it is planning to send a report, host does not send. 3 second MRT is expressed as 30. Hosts pick the MRT randomly b/w 0 and MRT timer.
        IGMPv1 router takes 3 minutes to conclude that the last host on the subnet has left the group as opposed to IGMPv2 router, it takes only 3 seconds.!
        IGMPv2 leave group and IGMPv2 Group-Specific query message work together.
        Last Member Query Interval by default is the MRT which is 10 (1 second). The router sets the Last Member Query Count to 2. So the leave latency is less than 3 second usually.
        IGMPv2 querier: when multiple routers are connected to a subnet. The router with the LOWEST IP address on the subnet is elected as the IGMP querier. “OTHER Querier Present Interval”. Default value is 255 seconds, because the default general IGMPv2 query interval is 125 seconds and default query response interval is 10 seconds.
        IGMPv2 Host and IGMPv1 Routers: IGMP v2 hosts determines whether the router is v1 or v2 by the MRT fields of the periodic general IGMP query. IGMPv1 queries, this field is ZERO. IGMPv2 Host “version 1 router present timeout” timer is 400seconds.
        IGMPv1 Host and IGMPv2 routers: determines by IGMPv1 report and figures it out. With one or more IGMPv1 hosts listening for a particular group, the router essentially suspends the optimizations that reduce leave latency. IGMPv1-host-present countdown timer = 180 in IGMPv1 and 260 seconds IGMPv2. (based on Group membership interval).
        IGMPv3: allows a host to filter incoming traffic based on the source IP addresses from which it is willing to receive packets, through a feature called “Source-Specific Multicast” (SSM). It allows a host to indicate interest in receiving packets only from specific source addresses or from all but specific source addresses, sent to a particular multicast address.
        destination address is 224.0.0.22 for IGMPv3 report. Message type is 0×22.
        How does a host learn group source addresses? Cisco has designed URL Rendezvous Directory (URD) and IGMPv3 Lite to use the new features of IGMPv3 is fully available.
    LAN Multicast Optimizations
        CGMP: L2 protocol, permits router to communicate L2 information it has learned from IGMP to switches.
        only routers generate CGMP messages, switches listen. CGMP needs to be enabled on both ends of the router-switch connection over which CGMP is operating.
        Destination Address on the CGMP messages is always well known MAC 0×0100.0cdd.dddd.
        Important info in CGMP messages is: Group Destination Address (GDA) and Unicast Source Address (USA).
        router sends a CGMP join message (every 60s) with GDA=0, and USA=it’s own mac.
        when router receives a join request from a host, it sets the DA=well known mac, USA=host’s MAC, and GDA=group Mac. “A host with USA MAC of xx has requested multicast traffic for the GDA…., so map your CAM tables accordingly”
        Leave: R1 sends GDA=group, and USA=0, to say that no host is interested.
        “clear ip cgmp” command is entered at the router for clearing all CGMP entries on the switches, the router sends the “delete all groups”, CGMP leave message with gda and usa set to 0. When switches receive these messages, they delete all group entries from CAM tables.
    RGMP: is a l2 protocol that enables a router to communicate to a switch which multicast group traffic the router does and does not want to receive from the switch. Router can reduce its overhead this way.

Read More