About mheusing

mheusing · ‎07-26-2009

Hi Sultan, What do you try to achieve with FRR? Which requirements do you have to meet? What is the existing network looking like, which platforms, what kind of links? I find it hard to discuss a technical solution without a context and some requirements. Regards, Martin

mheusing · ‎04-08-2009

Hi, I guess you are looking at "show mpls forwarding-table". The output will only contain labels assigned to networks, where packets could be forwarded to by cef. Packets to connected networks are punted, hence do not show up. To see the imp-null labels please use "show mpls ldp binding", which displays the LIB. It contains all the locally assigned labels plus the ones learned through LDP for every network including the connected ones. Hope this helps! Regards, Martin

mheusing · ‎12-05-2008

Hi, a couple of general remarks: Frame Relay (FR) switches like the Cisco IGX can be configured how to handle congestion and FECN/BECN. One option is not to send FECN/BECN to customer FR routers. This choice allows the SP to hide congestions in his network from the customer. Most SPs were overbooking their network, which means there will be congestion, if every customer sends at CIR. Not every SP would like to admit that ... I have seen overbooking by a onsiderable factor, e.g. customer buys 128k CIR and the SP reserves 16k in his network. Note: not every FR SP does this. Another option in a FR switch is to send FECN/BECN in a congestion case. What is congestion? Really it is defined by a certain threshold in the interface queues of the FR switches. So if a inetrface queue for a certain PVC class in a FR switch is filling up above a certain level the frames in the queue would get the FECN bit set. To speed up the feedback process ("Please slow down dear sender or I have to drop your frames!") one could also send a BECN in the opposite direction to the routers contributing to congestion. So the FR SP would not rely on the customer equipment doing FECN to BECN reflection. The general idea of informing about congestion was also introduced in L3 by using two bits in the TOS byte of the IP header. This was called ECN and is defined in RFC 3168 (The Addition of Explicit Congestion Notification (ECN) to IP). It can be configured, if WRED is used, to not drop an IP packet in the random drop range but mark ECN instead. There is, however, no FECN/BECN to ECN bit reflection as far as I know because ECN is independent of L2 transport. The router receiving the ECN bit in IP is supposed to reduce TCP window size the same way as if the packet was dropped by WRED. Reducing the window size is reducing TCP throughput. Regards, Martin

mheusing · ‎12-03-2008

Hi, From IOS XR 3.7 onwards besides eBGP and static also EIGRP is supported for PE-CE in VPNv6/6VPE. Regards, Martin

mheusing · ‎12-02-2008

Hi, The usage of AS path filters and prefix-lists targets different filtering scenarios. AS path lists will only filter based on AS path, but has not prefix specific component. prefix-lists do not have any AS specific component. So it looks to me that in your case you should apply both as input filters. This can be done either separately with two statements "neighbor a.b.c.d filter-list 1 in" with a "ip as-path access-list 1" and "neighbor a.b.c.d prefix-list XYZ in" or you can combine both in a route-map: neighbor a.b.c.d route-map customer in route-map customer permit 10 match as-path 1 match ip address prefix-list XYZ The two match statements in the route-map are ANDed and will only allow certain prefixes from the customer AS. Hope this helps! Please use the rating system. Regards, Martin

mheusing · ‎11-18-2008

Hi Rogelio, This should be possible with vrf aware IP SLA. Have a look at http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_05.html#wp1032476 You will also get the minimum IOS versions required for vrf aware IP SLA from the command reference. Regards, Martin

mheusing · ‎11-18-2008

Hi Sriram, Your description is correct. Usually the top label points to the BGP next hop, which in 6PE usually is the IPv4 address of the Loopback of the egress PE. The default is to allocate implicit null for it resulting in PHP and the egress PE will forward the packet based on the bottom label. If you do not want to use PHP you can configure a PE to allocate an explicit null label to the directly connected networks including the BGP next hop address. Then the penultimate LSR will send bottom label plus explicit null. The egress PE will remove the explicit null label and forward the packet based on the bottom label. So with PHP there is one label lookup less than without PHP, but forwarding is not changed, because ultimately in both cases it is based on the bottom label (usually assigned to the IPv6 prefix). The only configuration required is to enforce the allocation of the explicit null label, which is done with the command: Router(config)#mpls ldp explicit-null A detailed description of the command with all the options can be found for example at http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_m2.html#wp1076838 Hope this helps! Please use the rating system. Regards, Martin

mheusing · ‎11-11-2008

Full ACK, Joseph, you are right. Regards, Martin P.S.: Considering the tricks my memory sometimes does on me, I never would like to be dependent on eye witnesses and a jury ...

mheusing · ‎11-11-2008

Hi Joseph, The ECN bit would be set by a router with WRED being in the random drop range. It replaces the drop of a packet with an ECN bit marking, if the flow is ECN capable. The packet with ECN bit set is received by the receiver, who would then adjust the receive window in a TCP session, just like it would have, if a dropped packet was detected. The receive window in TCP translates to throughput with TCP throughput = window size/round trip time So the source would not know anything about the congestion, but rather follow the receivers window size adjustments thus adjusting the throughput of the flow. The ECN idea has some challenges, imho. Any misbehaving host gets an advantage. Assume I modify my TCP stack so that I am ECN capable, but after receiving ECN bits set I will NOT lower the window size, hence not lowering my throughput. If all other systems throttle their sessions because of the congestion experienced, whereas I send at full throughput, misbehaving is encouraged. With all the creative file sharers in the internet (providing f.e. clients capable of setting DSCP bits to get an advantage) I doubt that an ISP easily can rely on ECN bits instead of packet dropping with WRED. In an Enterprise environment, where one can control all involved gear this might be a different situation. Regards, Martin

mheusing · ‎11-11-2008

Hi, Please note that the performance data assumes 64 Byte packets, which is not the case for your FTP traffic. Assuming 1500 Bytes instead of 64 Bytes you could get up to 240 Mbps under optimum conditions, which might not be realistic in your case. For the time being you could simply fix the interface speed of the FastEthernet to 10 Mbps, which should solve the issue until you get a more powerful platform. If your connected equipment does not allow that you could configure a shaper on the FE. By trying various rates you likely could adjust the shaper to what the router can take without causing issues to ICMP or any other traffic. Regards, Martin

mheusing · ‎11-11-2008

Hi, I would turn on CEF, if it isn't already. Have a look at the service policy, which can contribute to CPU load depending on which kind of traffic you have. Can you also show the output of "show proc cpu history" and "show interface" preferably with a load interval of 30 sec? So far there is no consistent picture allowing to spot the culprit. Regards, Martin

mheusing · ‎11-11-2008

Hi, VLANoMPLS is basically a point to point solution. Looking at it at the ethernet frame level: it is an instruction for a LSR to send all dot1q frames of a certain VLAN to another LSR. Thus you cannot setup your required Hub and Spoke solution with VLANoMPLS/EoMPLS because you can only send a dot1q frame arriving in VLAN X to ONE other LSR. This solution also does not include learning of MAC addresses, which could be used to sort frames to different VCs. So you either could use a VPLS solution - which might be a bit of an overkill - or you could setup VLANoMPLS to a trunk from the LSR out to a router/switch and interconnect the VLANs there. It really depends on the connectivity requirements you have. Why do you need layer2 hub and spoke connectivity? Which underlying issue prevents any-to-any being a candidate? Regards, Martin

mheusing · ‎11-11-2008

Hi, To reinforce what Jon wrote: a) The router who comes up first will be DR and the second one BDR. DR/BDR election in OSPF is non-preemptive, so who got the job keeps the job. IF an election process takes place RouterA will be DR and router C will be BDR. b) Yes, if a DR/BDR election takes place So in brief: 1) If there is no existing DR on a LAN and no other OSPF router as seen from the Hellos, then the router declares itself as DR unless the priority is set to 0. 2a) If there is already a DR and a BDR no change will occur, independent of priority. DR and BDR will keep their role, even if they have a smaller priority. 2b) If there is no BDR but a DR then the router will become BDR. 2C) If there is no DR and no BDR and Hellos from several routers are seen (all with 0.0.0.0 in the DR and BDR field) then election takes place. The routers must be able to form an adjacency (matching area, authentication, password, stub bit, etc. ..). 3) A priority of 0 means no DR or BDR role. Regards, Martin

mheusing · ‎11-11-2008

Hi, As this thread is more active I'll repost my answer from the MPLS forum, which I found first. Hi, It is inevitable for all MPLS environments that there will be pure IP networks, which get MPLS labels assigned. It can be explained in different ways. Answers to your question: A1) MPLS is a transport technology transparent to the IP end systems (like PCs). Thus an edge MPLS router will have to assign labels to "pure IP networks". Otherwise no MPLS labels could be assigned to those networks which traffic should be transported. A2) MPLS label allocation - by default - follows a simple rule: allocate a label to every IP route except if it is learned by BGP. Locally assigned labels are sent to all LDP neighbors. A MPLS router does neither know, if a neighbor will ever use those labels nor, if it is essentials to have a label. Assume as an example you have configured MPLS L3VPN with your R1 routers 14.0.0.0/8 address as next hop. Then it would be crucial not to use "unlabeled/untagged", as this would break connectivity. LDP cannot "know" BGP next hops used somewhere in your network. Therefore the default label allocation scheme is as described and observed. Note: LDP can be configured with selective label allocation, as the network administrator knows, what LDP can not. In your example you could restrict LDP to only allocate/announce labels for loopback addresses. Then the behaviour you expected from the beginning could be observed. As depicted in A2) misconfigured selective label allocation can break connectivity in MPLS networks. Hope this helps! Please use the rating system. Regards, Martin

mheusing · ‎11-11-2008

Hi, For IOS 12.4 I would recommend the command reference : http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_book.html For the "policy-map" and "class-map" commands especially have a look at: http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_n1.html#wp1033055 http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_a1.html#wp1047911 One note though, as you did not specify any hardware: please be aware that there might be slight deviations in different platforms. In case you are looking for information about these commands for a particular hardware platform, please consult the QoS command reference of that platform. Hope this helps! Please use the rating system. Regards, Martin

Date Registered	‎06-19-2007 12:06 AM
Date Last Visited	‎05-10-2018 01:55 AM
Total Messages Posted	455
Total Helpful Votes Received	999

Re: MPLS TE tunnel protection (FRR) in ...

Re: MPLS confusion !

Re: FrameRelay Explicit Congestion Noti...

Re: OSPFv3 as a PE-CE

Re: Query for BGP

Re: vrf-based static ip routing, bounde...

Re: 6PE without PHP

Re: ECN with WRED doubt?

Re: ECN with WRED doubt?

Re: High CPU on 2611XM 12.3(26) during ...

Re: High CPU on 2611XM 12.3(26) during ...

Re: EOMPLS HUB AND SPOKE

Re: OSPF DR selection question

Re: Mpls query !

Re: Anyone can you provide link for pol...