You may have typed it up incorrectly but you appear to have applied the NAT pool to your internal interface, but the NAT pool belongs to the subnet on your outside interface. As you are using dynamic NAT, I am going to assume that you are wanting to NAT the internal IPs as they go externally so you need to change the NAT pool to be a 192.168.1.x range, assuming the interface NAT commands are correct, else, swap these interface NAT commands.
Hope this is of help, Matt Thompsopn -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 30 March 2013 16:21 To: [email protected] Subject: cisco-nsp Digest, Vol 124, Issue 82 Send cisco-nsp mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/cisco-nsp or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of cisco-nsp digest..." Today's Topics: 1. Re: Cisco and BGP MED (Harold Ritter (hritter)) 2. Re: Cisco ASA static dhcp binding (Bruce Pinsky) 3. how NAt works from outside to inside (s m) 4. Re: community on bgp update (Oliver Boehmer (oboehmer)) 5. Re: netflow with source-mac address? (Phil Mayers) 6. Re: netflow with source-mac address? (Gert Doering) ---------------------------------------------------------------------- Message: 1 Date: Fri, 29 Mar 2013 22:34:49 +0000 From: "Harold Ritter (hritter)" <[email protected]> To: Brandon Ewing <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [c-nsp] Cisco and BGP MED Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Hi Brandon, See comments inline. Le 2013-03-29 16:14, ? Brandon Ewing ? <[email protected]> a ?crit : >Is there a knob in Cisco IOS to enable sending the MED learned from an >iBGP peer to an eBGP peer? No. You can't propagate a MED received via iBGP to an eBGP neighbor but you could set the MED from the IGP metric to the BGP next-hop as follow: router bgp x neighbor y.y.y.y remote y neighbor y.y.y.y route-map setMed route-map setMed permit 10 set metric-type internal >Currently, it appears that if an iBGP route is learned from a local >network/aggregate statement, the MED is sent to an eBGP peer, but if >the iBGP route is learned from an iBGP peer, no MED is set on the >update to the eBGP peer. HR> This is normal behaviour. If the MED is learnt over iBGP it will not be sent to an eBGP neighbor. > > >Confirmed this in my 7206VXR lab, appears to be so in production on my >Sup720s, but my Foundry MLX series appear to send the learned MED >regardless. > >Lab output (Route sourced by netowrk statement on R21, advertised to R2 >in same AS, who advertises it to R1 in different AS): > >R21#show ip bgp 192.168.40.0 >BGP routing table entry for 192.168.40.0/24, version 2 >Paths: (1 available, best #1, table Default-IP-Routing-Table) > Advertised to update-groups: > 1 > Local > 0.0.0.0 from 0.0.0.0 (2.2.2.21) > Origin IGP, metric 10000, localpref 100, weight 32768, valid, >sourced, local, best > >R2#show ip bgp 192.168.40.0 >BGP routing table entry for 192.168.40.0/24, version 2 >Paths: (1 available, best #1, table Default-IP-Routing-Table) > Advertised to update-groups: > 2 > Local > 2.2.2.21 (metric 65) from 2.2.2.21 (2.2.2.21) > Origin IGP, metric 10000, localpref 100, valid, internal, best > > >R1#show ip bgp 192.168.40.0 >BGP routing table entry for 192.168.40.0/24, version 3 >Paths: (1 available, best #1, table Default-IP-Routing-Table) > Not advertised to any peer > 65002 > 1.1.2.2 from 1.1.2.2 (2.2.2.2) > Origin IGP, localpref 100, valid, external, best > >-- >Brandon Ewing >([email protected]) ------------------------------ Message: 2 Date: Fri, 29 Mar 2013 18:21:40 -0700 From: Bruce Pinsky <[email protected]> To: Andrey Petrenko <[email protected]> Cc: [email protected] Subject: Re: [c-nsp] Cisco ASA static dhcp binding Message-ID: <[email protected]> Content-Type: text/plain; charset="UTF-8" On Fri, 29 Mar 2013 19:16:11 +0300, Andrey Petrenko <[email protected]> wrote: > Hello everyone! I have Cisco ASA 5510 (8.4(5)). Can i configure dhcp > servers with static mapping? (e.g for mac xxxx:yyyy:zzzz assign ip > addr 192.168.1.100? > Unfortunately, no. -- ========== bpe ------------------------------ Message: 3 Date: Sat, 30 Mar 2013 13:17:00 +0430 From: s m <[email protected]> To: [email protected] Subject: [c-nsp] how NAt works from outside to inside Message-ID: <caa_1sgggnvk-dpbs+2ostnlsedpubxszs3yttfvfy0kn3+k...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 hello all i am newbie in NAT and i have some problem. i want to have a dynamic nat and this is my topology: 192.168.1.1-----> cisco 2800 ------> 192.168.2.1 and this is my configuration in cisco 2800: interface GigabitEthernet 0/0 ip address 192.168.2.2 255.255.255.0 ip nat outside ip virtual-reassebly in duplex auto speed auto interface GigabitEthernet 0/1 ip address 192.168.1.2 255.255.255.0 ip nat inside ip virtual-reassebly in duplex auto speed auto ip nat pool t 192.168.2.50 192.168.2.60 netmask 255.255.255.0 ip nat inside source list 1 pool t access-list 1 permit any when i ping 192.168.2.1 from 192.168.1.1 (from inside to outside), every thing is ok and nat is done correctly but when i ping 192.168.1.1 from 192.168.2.1 (from outside to inside), packets that received in 192.168.2.1 are as below: request packets: src:192.168.2.1----> dst: 192.168.1.1 reply packets: src: 192.168.2.50----> dst:192.168.2.1 and 192.168.2.1 system accept these packets as its reply!!! i think this behavior is wrong, isn't it? how it is happen? moreover, if i put a freebsd system instead of cisco, everything is the same except that 192.168.2.1 does not accept the reply packets as its reply (as i expected!!). please let me know if the cisco behavior is correct or not and if it is correct, how cisco router do that? please help me if i am misunderstanding. thanks in advance ------------------------------ Message: 4 Date: Sat, 30 Mar 2013 10:47:25 +0000 From: "Oliver Boehmer (oboehmer)" <[email protected]> To: Riccardo S <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [c-nsp] community on bgp update Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" On 29/03/2013 16:46, "Riccardo S" <[email protected]> wrote: >Hi >do I get the same result with route-map test-1 and test-2 in setting >these community on BGP update ? > >******************************* >route-map test-1 permit 10 >match ip address prefix-list site-a >set community 1:1 >set community 1:2 additive > > >******************************* >route-map test-2 permit 10 >match ip address prefix-list site-a >set community 1:1 >continue >! >route-map test-2 permit 20 >match ip address prefix-list site-a >set community 1:2 additive the result might be different, as the test-1 config results in this: route-map test-1 permit 10 match ip address prefix-list site-a set community 1:1 1:2 additive ! and this one would add both communities to any communities already on the route, while prefixes processed by test-2 will have only 1:1 1:2, with all other communities removed. > > >And could you please give me an example of a route-map that match the >route marked before with 1:1 and 1:1 + 1:2 ? > >I was wondering if this is ok: > >ip policy-list PERMIT100 permit >match community 1 >! >ip policy-list PERMIT200 permit >match community 2 >! >ip community-list 1 permit 1:1 >ip community-list 2 permit 1:2 >! >! >! >route-map only1-1 permit 10 <---- does it match only if it's present >1:1 ? >match policy-list PERMIT100 no, it will also match "1:1 1:2", you would need to use "match community 1 exact-match" in the policy-list. >route-map 1-2 permit 10 <---- does it match only if are >presend 1:1 AND 1:2 ? >match policy-list PERMIT100 >match policy-list PERMIT200 no, you would need to do match on "ip community-list 12 permit 1:1 1:2", which creates an AND. hth oli ------------------------------ Message: 5 Date: Sat, 30 Mar 2013 11:52:59 +0000 From: Phil Mayers <[email protected]> To: [email protected] Subject: Re: [c-nsp] netflow with source-mac address? Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 03/29/2013 06:41 PM, Nick Hilliard wrote: > On 29/03/2013 17:38, Gert Doering wrote: >> So that would also exclude Sup2T-based systems, using LAN cards (67/68/69xx)? > > Honestly, I don't know. The DFC4 on the lan cards may fix this. Maybe > someone from Cisco can clarify? This: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps11821/ps11846/product_bulletin_c25-717747_ps708_Products_Bulletin.html ...talks about 15.1(SY) on the sup2T and says: """NetFlow (TNF) Export L2 MAC and Port Information for IPv4 This feature gives you a way to find out the NetFlow information for destination and source MAC address along with the port LTL. This is useful when a bot on the network is spoofing the IP address. We will be able to track this down with the MAC address using NetFlow.""" I had a feeling I'd seen mention of that feature. ------------------------------ Message: 6 Date: Sat, 30 Mar 2013 13:13:57 +0100 From: Gert Doering <[email protected]> To: Phil Mayers <[email protected]> Cc: [email protected] Subject: Re: [c-nsp] netflow with source-mac address? Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi, On Sat, Mar 30, 2013 at 11:52:59AM +0000, Phil Mayers wrote: > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps11821/ps11846/product_bulletin_c25-717747_ps708_Products_Bulletin.html > > ...talks about 15.1(SY) on the sup2T and says: > > """NetFlow (TNF) Export L2 MAC and Port Information for IPv4 > This feature gives you a way to find out the NetFlow information for > destination and source MAC address along with the port LTL. This is > useful when a bot on the network is spoofing the IP address. We will be > able to track this down with the MAC address using NetFlow.""" This is extremely cool. I'm somewhat disappointed by the "for IPv4" bit, though. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20130330/6a82ef8f/attachment-0001.sig> ------------------------------ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp End of cisco-nsp Digest, Vol 124, Issue 82 ****************************************** ______________________________________________________________________ This email has been scanned by the brightsolid Email Security System. Powered by MessageLabs ______________________________________________________________________ ______________________________________________________________________ "brightsolid" is used in this email to collectively mean brightsolid online innovation limited and its subsidiary companies brightsolid online publishing limited and brightsolid online technology limited. findmypast.co.uk is a brand of brightsolid online publishing limited. brightsolid online innovation limited, Gateway House, Luna Place, Dundee Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC274983. brightsolid online publishing limited, The Glebe, 6 Chapel Place, Rivington Street, London EC2A 3DQ. Registered in England No. 04369607. brightsolid online technology limited, Gateway House, Luna Place, Dundee Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC161678. Email Disclaimer This message is confidential and may contain privileged information. You should not disclose its contents to any other person. If you are not the intended recipient, please notify the sender named above immediately. It is expressly declared that this e-mail does not constitute nor form part of a contract or unilateral obligation. Opinions, conclusions and other information in this message that do not relate to the official business of brightsolid shall be understood as neither given nor endorsed by it. ______________________________________________________________________ This email has been scanned by the brightsolid Email Security System. Powered by MessageLabs ______________________________________________________________________ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
